Menu
I have a project that uses this technique that work fine in JDK 8 and older. However, in JDK 9 this jar was removed and it does no longer work:
'dependencies.dependency.systemPath' for com.sun:tools:jar refers to a non-existing file /usr/lib/jvm/java-9-jdk/../lib/tools.jar. Please verify that you run Maven using a JDK and not just a JRE.
(The path looks strange, though there is no tools.jar in JDK 9)
What is the best practice that would work across JDK versions and perhaps even JDK vendors? I have not even found any workaround for JDK 9 on OpenJDK (while keeping the project buildable on JDK 8).
768
the executable jar should NOT contain the dependencies, just enough of your own code to run, with the dependent classes coming from the before mentioned classpath set up in the manifest.
The --add-opens option You can use the --add-opens runtime option to allow your code to access non-public members. This can be referred to as deep reflection. Libraries that do this deep reflection are able to access all members, private and public.
The --add-exports option allows code in the target module to access types in the named package of the source module if the target module reads the source module.
Your problems are caused by the Project Jigsaw changes that went into the Java 9 EA build you seem to have used. JEP 220 describes them.
The section Removed: rt.jar and tools.jar describes this in more detail but Risks and Assumptions contains a good summary:
JDK and JRE images will, as noted above, no longer contain the files
lib/rt.jar,lib/tools.jar,lib/dt.jar, and other internal jar files. Existing code that assumes the existence of these files might not work correctly.
So as you observed, those files are gone. Further down:
Class and resource files previously found in
lib/tools.jarand visible only when that file was added to the class path will now, in a JDK image, be visible via the system class loader or, in some cases, the bootstrap class loader. The modules containing these files will not, however, be mentioned in the application class path, i.e., in the value of the system propertyjava.class.path.
So the classes from tools.jar are moved into modules but it seems like they might not be available to the user. You should use jdeps from a recent Jigsaw build...
$jdeps -M -s $your_JAR
jdeps -jdkinternals $your_JAR
If you're lucky, the API you are using was published (then it will not show up in the second analysis) or have a public alternative (which the second analysis would list ). Otherwise you should consider taking this to the Jigsaw mailing list and ask for help there, noting explicitly which APIs you are using and what for.
140
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
