I think I know where the issue is. Can you send me your test and I can modify and include it in this patch?
Mandy > On May 12, 2016, at 10:31 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Hi Mandy, > > I am a bit surprised that the verbose option doesn't seem > to have any effect on the output of jdeps -I > > I have built 4 jars: > > unsafe.jar has some class that depend directly on > sun.misc.Unsafe, and some that don't. > indirect.jar has some classes that depends indirectly > on sun.misc.Unsafe: they depend on classes > from unsafe.jar that depend on sun.misc.Unsafe. > It also has classes that don't depend on sun.misc.Unsafe, > either directly or indirectly. > indirect2.jar also has some classes that depends indirectly > on sun.misc.Unsafe: they depend on classes > from unsafe.jar that depend on sun.misc.Unsafe. > It also has classes that don't depend on sun.misc.Unsafe, > either directly or indirectly. > safe.jar has classes that depends on other classes in > unsafe.jar, indirect.jar, and indirect2.jar > However the classes it depends on do not depend on > sun.misc.Unsafe, either directly or indirectly. > > If I run: > $ ./bin/jdeps -I -e sun.misc.Usafe -modulepath ~/test/JdepsTest/dist > -addmods unsafe,safe,indirect,indirect2 > > Inverse transitive dependences matching sun.misc.Usafe > indirect <- safe > indirect2 <- safe > unsafe <- indirect <- safe > unsafe <- indirect2 <- safe > unsafe <- safe > > So it looks like the granurality of the analysis is performed > at module level. Is there anyway to make the analysis at class > level, so that 'safe' isn't reported to depend on sun.misc.Unsafe? > > I tried passing -verbose:class or -v but it doesn't appear to have any > effect, the result is always the same. > > best regards, > > -- daniel > > On 12/05/16 18:45, Mandy Chung wrote: >> This patch applies on the top of the jdeps refresh patch [1].. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156575/webrev.01/ >> >> The -addmods option is the same as what the runtime supports so that we >> can run jdeps in the same command-line options as runtime. -system is >> to specify an alternative java.home. >> >> -inverse option will find the modules that depend on a given root module >> directly and indirectly. It’s useful to use with the -requires option >> or -package, -regex options: >> >> Example output: >> $ jdeps -I -mp mods -addmods m4,m5 -requires java.logging >> java.sql >> [jrt:/java.sql] >> requires mandated java.base >> requires public java.logging >> requires public java.xml >> java.sql -> java.logging >> java.sql -> >> java.util.logging java.logging >> javax.sql -> >> java.util.logging java.logging >> m5 >> [file:///scratch/mchung/ws/jdk9/jdk9-jdeps/JTwork/scratch/mods/m5/] >> requires mandated java.base >> requires public java.compiler >> requires public java.logging >> requires java.sql >> requires public m4 >> m5 -> java.logging >> p5 -> >> java.util.logging java.logging >> >> Inverse transitive dependences on [java.logging] >> java.logging <- java.sql <- m5 >> java.logging <- m4 <- m5 >> java.logging <- m5 >> >> $ jdeps -I -mp mods -requires jdk.unsupported -m java.se <http://java.se> >> java.desktop >> [jrt:/java.desktop] >> requires mandated java.base >> requires public java.datatransfer >> requires java.prefs >> requires public java.xml >> requires jdk.unsupported >> java.desktop -> jdk.unsupported >> sun.awt -> sun.misc >> jdk.unsupported (internal) >> sun.awt.image -> sun.misc >> jdk.unsupported (internal) >> >> Inverse transitive dependences on [jdk.unsupported] >> jdk.unsupported <- java.desktop <- java.se <http://java.se> >> >> >> [1] http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.01/ >> >
