JDK-8147794 : Jlink's ModuleEntry.stream can't be consumed more than once and ModuleEntry content should be read only if needed
  • Type: Sub-task
  • Component: tools
  • Sub-Component: jlink
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-01-20
  • Updated: 2016-06-30
  • Resolved: 2016-06-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b125Fixed
Related Reports
Relates :  
JDK-8147491 - module graph consistency checks after jlink plugins operate on module pool
Description
If the same stream is read in multiple plugins, then this could be difficult to investigate.
For example:
In plugin m1, the stream of a ModuleData instance is read then the ModuleData instance is added to the output pool (and not replaced by a new instance). 
If plugin m2 tries to read the stream, it will get a consumed stream.

We could:
- if markIsSupported, mark the stream at creation time, reset it each time it is returned.
- if !markIsSupported, read the stream fully and expose a new ByteArrayInputStream when required.
Comments
In addition to stream handling, getBytes() directly exposes byte[] which can be modified from elsewhere. Also, streams are opened and read from Archives even if those won't be consumed (say ModuleEntries being filtered). We need to read ModuleEntry content only if needed and internal byte buffer should not be exposed. Calling stream() multiple times should do the expected thing.
24-06-2016