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


Please review the latest webrev for this issue.

issue: https://bugs.openjdk.java.net/browse/JDK-8156499 
webrev: 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 
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.


Reply via email to