>> 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).
I took that out and it still works as expected. > Are directories the only case where toEntry can return null, in which case > would it simpler to filter out directories here. I’ve done that too. > > 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’ve made JarFile available via a protected method > > 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
