Can jdeps resolve unnecessary dependencies?

Sander Mak sander.mak at
Thu Sep 8 11:15:50 UTC 2016

Hi Waldek,

I feel the other responses focus too much on your side-remark on reflection.

What you're seeing here with jdeps is not unexpected behavior, I believe. For example, log4j *does* reference awt code [0], even though you might not expect it. Same holds true for swing classes [1]. It's just when you run it on a full JDK, you're not aware of this dependency! Hurray for modularity, making it clear that you need awt to use log4j... (and therefore, transitively your app.jar if it uses log4j classes). Now this ColorRule [0] class may never be loaded in any of your usage scenarios, but that doesn't mean the dependency is not there.

Hope this helps,



On 08 Sep 2016, at 00:34, Waldek Kozaczuk <jwkozaczuk at<mailto:jwkozaczuk at>> wrote:

Thanks for your responses.

So today I did some experimentation with Java 8 jdeps to analyze how my
app.jar depends at class level on other jars and eventually individual JRE
classes. I would run following command:

jdeps -v -P -R -cp lib/* app.jar # where lib/ contains jars that app.jar
depends on to run and libs did not contain app.jar

It turns our that jdeps would find and present dependent classes in all
jars irregardless if any class in app.jar would directly or indirectly
depend on it per "->" references.

The good example of it was log4j jar where jdeps showed number of classes
that depend directly or indirectly on some java.awt.* or javax.swing.*
classes. And I am sure that this app does not requires AWT nor Swing to
execute. Is it because jdeps finds individual class dependencies by
detecting reflection calls in bytecode of log4j?

Or maybe this "greedy" behavior of jdeps is intende and I would need to
build a tool that would process its generated dependency graph starting
from app.jar and that way find the real subset of JRE it depends on? I am
still thinking that jdeps would not be able to show me classes that were
called through java.lang.reflect.* constructs or Class.forName().

Do my findings make sense?

On Wed, Sep 7, 2016 at 5:03 PM, Mandy Chung <mandy.chung at<mailto:mandy.chung at>> wrote:

On Sep 7, 2016, at 8:07 AM, Sander Mak <sander.mak at<mailto:sander.mak at>> wrote:

On 07 Sep 2016, at 16:12, Waldek Kozaczuk <jwkozaczuk at<mailto:jwkozaczuk at>> wrote:

Will I be able to take advantage of jlink's ability to produce
image of the JRE even if I do not use new Java 9 modular jars? In other
words if my app.jar and other dependent jars are old java 8 ones and do
have any module descriptors will jlink be able to identify only needed
modules and produce minimal runtime image?

Jlink will not be able to do that for you without module descriptors,
but there's an alternative solution. First, use jdeps to find all the
platform modules your application needs. Then create an image using jlink
with an --add-modules <platform_module> argument for each of the identified
platform modules. You can then run your existing application with all
application/library JARs on the classpath on top of the resulting image.

As Sander said, jlink creates custom image from packaged modules only. You
can create a minimal runtime image and your application and other libraries
can be put on the classpath.

The open issue of adding link-time support for automatic modules is
JDK-8139947 [1].


More information about the jigsaw-dev mailing list