RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

[Alan Bateman]

On 13/10/2016 00:00, Steve Drach wrote:

> Hi,
>
> Please review the latest webrev for this issue.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8156499 <https://bugs.openjdk.java.net/browse/JDK-8156499>
> webrev: http://cr.openjdk.java.net/~sdrach/8156499/webrev.03/ <http://cr.openjdk.java.net/~sdrach/8156499/webrev.03/>
>
> I believe this changeset resolves all the issues Alan and Mandy had with the previous changesets.  They are:
>
> 1. the test silently passes if java.base.jmod can not be found on the module-path
> 2. the test assures that
>      a. the correct module-info class is in the module image
>      b. the correct resource file is in the module image
>      c. the correct class file is in the module image
> 3. As before, the image module created is for the Runtime.Version of jlink.  This demonstrates that MMR jar files
>      are handled correctly, but will have to be updated to create an image based on the Runtime.Version of java.base
>      when the appropriate code is migrated from jake.
>
In JarArchive::entries then you filter out META-INF/MANIFEST.MF and I'm 
not sure that that is right (think modular JAR on the module path with a 
manifest, it's just a resource file). Are directories the only case 
where toEntry can return null, in which case would it simpler to filter 
out directories here.

There is quite a bit of clean-up needed in this area (pre-dates your 
patch of course). Not clear why Archive isn't a Closeable for example, 
or why covariant returns aren't used by the more specialized 
JarArchive/JarEntry/etc. I'm sure you don't want to get into that but 
maybe we could at least make the JarFile available via a protected 
method rather than a field.

I don't have time just now to go through the test in detail but having 
it pass silently when on exploded build (no packaged modules) looks right.

-Alan