jdeps is only doing static analysis and doesn’t inspect reflection usage.  It’s 
possible to build such an automated process but not reliable.  Convert the app 
to modules with explict dependences will ensure reliable configuraton.

AFAIK javapackager has a RFE to provide this functionality (analyze the static 
dependences and package the app with a minimal image) while this does not 
detect any reflective dependences. 

Mandy
P.S. please try jdk9 jdeps and see if you get the same behavior.

> On Sep 7, 2016, at 3:42 PM, Waldek Kozaczuk <jwkozac...@gmail.com> wrote:
> 
> My real question I am in pursuit of answering is this: is it in theory 
> possible to build an automated process that would use jdeps to analyze my app 
> to build a minimal JRE image it would run on? The latter could be done by 
> rewriting rt.jar in Java 8 and using jlink in Java 9. 
> 
> Sent from my iPhone
> 
> On Sep 7, 2016, at 18:34, Waldek Kozaczuk <jwkozac...@gmail.com> 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.ch...@oracle.com> wrote:
>> 
>> > On Sep 7, 2016, at 8:07 AM, Sander Mak <sander....@luminis.eu> wrote:
>> >
>> >
>> >> On 07 Sep 2016, at 16:12, Waldek Kozaczuk <jwkozac...@gmail.com> wrote:
>> >>
>> >> Will I be able to take advantage of jlink's ability to produce subset-only
>> >> 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 
>> >> not
>> >> have any module descriptors will jlink be able to identify only needed JRE
>> >> 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].
>> 
>> Mandy
>> [1] https://bugs.openjdk.java.net/browse/JDK-8130047
>> 
>> 
>> 

Reply via email to