Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options

[Daniel Fuchs]

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/
>