Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to express dependency in maven on java ee features for transition to Java 9?

Tags:

We use maven and have artifacts that in turn depend on other internal artifacts. I am in the process of migrating to java-9, and intend to migrate everything to Java 9 first without modularizing the code (i.e. in the unnamed module).

The problem I run into is that we depend on java.xml.bind, which is now not included in the default modules. Is there a "correct" way to express this dependency on java.xml.bind with Maven?

like image 370
Kevin Peterson Avatar asked Sep 06 '17 21:09

Kevin Peterson


People also ask

How do I add a dependency in Maven?

Add a Java Maven Dependency to the Utility ProjectRight-click the utility project, and select Maven>Add Dependency. Type a dependency name in the Enter groupID… field (e.g., commons-logging) to search for a dependency. Select the dependency, and click OK.

What is the difference between Java SE and Java EE?

Java SE is use for the desktop applications and simple core functions. Java EE is used for desktop, but also web development, networking, and advanced things. Save this answer.

Which scope indicates that dependency is available in classpath of project?

Dependency Scope Sr.No. This scope indicates that dependency is available in classpath of project. It is default scope. This scope indicates that dependency is to be provided by JDK or web-Server/Container at runtime.

What is runtime dependency in Maven?

runtime. This scope indicates that the dependency is not required for compilation, but is for execution. Maven includes a dependency with this scope in the runtime and test classpaths, but not the compile classpath.


1 Answers

The Module System speaks of the way the unnamed modules as in your case of loading the application from classpath constructs the module graph. Further, from the documentation itself:-

When the compiler compiles code in the unnamed module, or the java launcher is invoked and the main class of the application is loaded from the class path into the unnamed module of the application class loader, then the default set of root modules for the unnamed module is computed as follows:

  • The java.se module is a root, if it exists. If it does not exist then every java.* module on the upgrade module path or among the system modules that exports at least one package, without qualification, is a root.

  • Every non-java.* module on the upgrade module path or among the system modules that exports at least one package, without qualification, is also a root.

Otherwise, the default set of root modules depends upon the phase:

  • At compile time it is usually the set of modules being compiled (more on this below);

  • At link time it is empty; and

  • At run time it is the application's main module, as specified via the --module (or -m for short) launcher option.

It is occasionally necessary to add modules to the default root set in order to ensure that specific platform, library, or service-provider modules will be present in the module graph. In any phase the option

--add-modules <module>(,<module>)* where <module> is a module name, adds the named modules to the default set of root modules.

Similar issue was faced in jetty.project where a thread from jdk mailing list discussed over the same and the fix was to use:

--add-modules java.se.ee 

which provided them access to all Java SE modules and in your case shall simply be:

--add-modules java.xml.bind 

To use this in maven, you can embed the same to the maven-compiler-plugin using

<compilerArgs>     <arg>--add-modules</arg>     <arg>java.xml.bind</arg> </compilerArgs> 

as suggested by ZhekaKozlov here.


An important point to note is that marking deprecation of an API also means you might probably want to get away from using it. To adapt to this way you can probably start consuming the dependency on jaxb-api:2.3.0 which can now be loaded as a module and can be executed from the classpath as well. The change you need to make is to add the following to your dependencies list:

<dependency>     <groupId>javax.xml.bind</groupId>     <artifactId>jaxb-api</artifactId>     <version>2.3.0</version> </dependency> 

Update:- Eventually, with Java-10 already out and JDK/11 up next, one should ideally follow the link to JEP 320: Remove the Java EE and CORBA Modules and further replace such dependencies with their standalone libraries instead.

like image 56
Naman Avatar answered Oct 15 '22 00:10

Naman