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
