8003562: Provide a command-line tool to find static dependencies

[Ulf Zibis]

Yeah, this is a great tool.

Does it also help to find the need to recompile a class if the source of a inlined referred static 
final constant has changed?

-Ulf


Am 28.11.2012 00:18, schrieb Mandy Chung:
> As part of prepare for modules [1], this RFE is to provide a command-line tool in JDK8 so that 
> developers can understand the static dependencies of their applications and libraries.As part of 
> Project Jigsaw, a useful class analyzer [2] was developed that makes it very easy to identify the 
> dependencies based on the classfile library thathas also been enhanced to support dependency 
> analysis [3].
>
> Inspired by the sample tool that Jon Gibbons developed, we propose this new command-line name as 
> "jdeps".
>
> $ ./bin/jdeps -h
> Usage: jdeps <options> <files....>
> where possible options include:
>   -version                 Version information
>   -classpath <path>        Specify where to find class files
>   -v  --verbose            Print class-level dependencies
>   -r  --reverse            Invert the dependencies in the output
>   -p                       Restrict analysis to classes in this package
>                            (may be given multiple times)
>   -e  --regex              Restrict analysis to packages matching pattern
>                            (-p and -e are exclusive)
>   -P  --profile            Show profile or the file containing a package
>   -d   --depth             Specify the depth of the transitive dependency analysis
>                            Default depth is 1.  Set depth to 0 to traverse all dependencies.
>   -all                     Show all classes and members with no breakdown
>
> The jdeps tool shows package-level dependencies of the input files that can be .class files, a 
> directory, or a JAR file. Specify the depth for the transitive dependency analysis; otherwise, it 
> only analyzes the input files.  jdeps -P option will show where the class/package comes from.  For 
> Java SE API, it will show the Profile name (I implement a workaround for now until the profile 
> work is in jdk8).  For JDK internal APIs, they will not be exported in modular world.  jdeps will 
> indicate any usage of the JDK internal APIs in the output to help developers prepare for 
> transitioning to modules.
>
> See below for a few sample output.
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8003562/
>
> The implementation classes for jdeps are in the langtools repo along with the 
> com.sun.tools.classfile library.  I'm working on adding more unit tests.  I'd like to get this 
> webrev out to begin the discussion and get review feedback.
>
> Thanks
> Mandy
> [1] http://openjdk.java.net/jeps/162
> [2] 
> http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/raw-file/543b0d24a920/make/tools/classanalyzer/classanalyzer.html
> [3] http://bugs.sun.com/view_bug.do?bug_id=6907575
>
> Sample Output
>
> $./bin/jdeps demo/jfc/Notepad/Notepad.jar
> <unnamed> (demo/jfc/Notepad/Notepad.jar)
>     -> java.awt
>     -> java.awt.event
>     -> java.beans
>     -> java.io
>     -> java.lang
>     -> java.net
>     -> java.util
>     -> java.util.logging
>     -> javax.swing
>     -> javax.swing.border
>     -> javax.swing.event
>     -> javax.swing.text
>     -> javax.swing.tree
>     -> javax.swing.undo
>
> $ ./bin/jdeps -P demo/jfc/Notepad/Notepad.jar
> <unnamed> (demo/jfc/Notepad/Notepad.jar)
>     -> java.awt                                 compact4
>     -> java.awt.event                           compact4
>     -> java.beans                               compact4
>     -> java.io                                  compact1
>     -> java.lang                                compact1
>     -> java.net                                 compact1
>     -> java.util                                compact1
>     -> java.util.logging                        compact1
>     -> javax.swing                              compact4
>     -> javax.swing.border                       compact4
>     -> javax.swing.event                        compact4
>     -> javax.swing.text                         compact4
>     -> javax.swing.tree                         compact4
>     -> javax.swing.undo                         compact4
>
> $ ./bin/jdeps -d 10 demo/jfc/Notepad/Notepad.jar
> <unnamed> (demo/jfc/Notepad/Notepad.jar)
>     -> java.awt
>     -> java.awt.event
>     -> java.beans
>     -> java.io
>     -> java.lang
>     -> java.net
>     -> java.util
>     -> java.util.logging
>     -> javax.swing
>     -> javax.swing.border
>     -> javax.swing.event
>     -> javax.swing.text
>     -> javax.swing.tree
>     -> javax.swing.undo
> java.security (/export/mchung/ws/jdeps-repo/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar)
>     -> javax.crypto
> javax.crypto (/export/mchung/ws/jdeps-repo/build/macosx-x86_64/j2sdk-image/jre/lib/jce.jar)
>     -> java.io
>     -> java.lang
>     -> java.lang.reflect
>     -> java.net
>     -> java.nio
>     -> java.security
>     -> java.security.cert
>     -> java.security.spec
>     -> java.util
>     -> java.util.concurrent
>     -> java.util.jar
>     -> java.util.regex
>     -> java.util.zip
>     -> sun.security.jca                         JDK internal API
>     -> sun.security.util                        JDK internal API
> javax.crypto.spec (/export/mchung/ws/jdeps-repo/build/macosx-x86_64/j2sdk-image/jre/lib/jce.jar)
>     -> java.lang
>     -> java.security.spec
>     -> java.util
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20121205/b4210c1e/attachment.html