Hi Steve, > On Jun 13, 2016, at 11:02 AM, Steve Drach <steve.dr...@oracle.com> wrote: > > Hi, > > 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? 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
