Hi Mandy, >> Please review the following changeset to make jdeps multi-release jar aware. >> >> webrev: http://cr.openjdk.java.net/~sdrach/8153654/webrev.00/index.html >> <http://cr.openjdk.java.net/~sdrach/8153654/webrev.00/index.html> >> issue: https://bugs.openjdk.java.net/browse/JDK-8153654 >> <https://bugs.openjdk.java.net/browse/JDK-8153654> >> >> The changeset adds a new command line option to jdeps. The -multi-release >> option can be set to the string “runtime” or an integral string value >> corresponding to the Java platform releases starting at 9 (i.e. 9, 10, 11, >> etc.). Jar files that jdeps accesses, either on the class path or as a >> target, are opened with the appropriate JarFile.Release parameter. The >> mapping from -multi-release value to JarFile.Release is: >> >> 9 -> JarFile.Release.VERSION_9 >> runtime -> JarFile.Release.RUNTIME >> all others -> JarFile.Release.BASE >> >> If the option is not present, the jar file mode is JarFile.Release.Base. > > Have you considered parsing all versioned entries in MRJAR as the default and > include the version information in the output?
Briefly ;-) But now that you brought it up, I think the right thing to do is to rescind this RFR and redesign the output for jdeps so that it’ll be more useful for the users by doing what you suggest. > > > A relevant implementation details: > > jdeps is using its runtime environment to analyse the class dependencies. > The potential missing information when analyzing a MR jar is some JDK > internal APIs not present in the current runtime but exists in the older > release. jdeps maintains a small list of the removed sun.misc and sun.reflect > internal APIs to emit useful information since existing libraries may depend > on those removed types that already have replacement; otherwise, they will be > shown as not found which is accurate as CNFE may be thrown if that library is > running on JDK 9. > > Mandy >
