Geek Answers Handbook

Declare maven dependency on tools.jar for working with JDK 9

I have a project that uses this method that works fine in JDK 8 and older. However, in JDK 9, this jar was deleted and it no longer works:

'dependencies.dependency.systemPath' for com.sun: tools: jar refers to a non-existent file / usr / lib / jvm / java -9-jdk /../ lib / tools.jar. Make sure you start Maven using the JDK, not just the JRE.

(The path looks weird, although there are no tools. Jar in JDK 9 )

What is the best practice that will work on JDK versions and possibly even on JDK vendors? I did not even find a workaround for JDK 9 on OpenJDK (while maintaining the project on JDK 8).

+6
source share
3 answers

Your problems are caused by changes to Project Jigsaw that are included in the Java 9 EA build that you seem to have used. JEP 220 describes them.

The Deleted section : rt.jar and tools.jar describes this in more detail, but Risks and Assumptions contain a good summary:

JDK and JRE images, as noted above, no longer contain the lib/rt.jar , lib/tools.jar , lib/dt.jar and other internal jar files. Existing code suggesting the existence of these files may not work correctly.

So, as you noticed, these files have disappeared. Further down:

Class and resource files previously found in lib/tools.jar and visible only when this file was added to the class path will now be displayed as JDK through the system class loader or, in some cases, the boot class loader, However, the modules, containing these files will not be mentioned in the class path of the application, i.e. In the value of the system property java.class.path .

So, classes from tools.jar move into modules, but it seems that they may not be available to the user. You should use jdeps from the recent Jigsaw build ...

  • ... to determine the dependencies of your module: $jdeps -M -s $your_JAR
  • ... for defining dependencies on JDK internal APIs: jdeps -jdkinternals $your_JAR

If you're lucky, the API you are using has been published (then it will not be displayed in the second analysis) or have a public alternative (which will be displayed in the second analysis). Otherwise, you should think about it on the Jigsaw mailing list and ask for help there, indicating explicitly which APIs you are using and for what.

+11
source

It turns out that the JDK 9 solution is no different from the original trick :

  <profiles> <profile> <id>jigsaw</id> <activation> <jdk>[1.9,)</jdk> </activation> <!-- No dependencies needed by Jigsaw --> <dependencies/> </profile> <profile> <id>default-jdk</id> <activation> <file> <exists>${java.home}/../lib/tools.jar</exists> </file> </activation> <dependencies> <dependency> <groupId>com.sun</groupId> <artifactId>tools</artifactId> <scope>system</scope> <version>1.6</version> <systemPath>${java.home}/../lib/tools.jar</systemPath> </dependency> </dependencies> </profile> <profile> <id>osx-jdk</id> <activation> <file> <exists>${java.home}/../Classes/classes.jar</exists> </file> </activation> <dependencies> <dependency> <groupId>com.sun</groupId> <artifactId>tools</artifactId> <scope>system</scope> <version>1.6</version> <systemPath>${java.home}/../Classes/classes.jar</systemPath> </dependency> </dependencies> </profile> </profiles>

If entire dependency declarations move to profile , it allows different profiles to use a different number of dependencies.

I created a reusable module to hide complexity from a separate project, which depends on tools.jar:

 <dependency> <groupId>com.github.olivergondza</groupId> <artifactId>maven-jdk-tools-wrapper</artifactId> <version>0.1</version> </dependency>
+4
source

The solution (a simple workaround) is considered broken and will not work with Java 9. All you can do is run jdeps and transfer your code to the public APIs.

0
source

More articles:


All Articles