Migrating from deprecated Java Platform Module System (JPMS) modules tied to Java EE APIs can feel like navigating a minefield. With the shift towards Jakarta EE, developers face the challenge of replacing outdated dependencies with their modern equivalents. This transition, while necessary for maintaining secure and up-to-date applications, requires careful planning and execution. This article will guide you through the process, providing clear replacements and best practices for a smooth migration.

Understanding the Deprecation

Several JPMS modules related to Java EE have been deprecated, signifying their eventual removal from future Java versions. This includes modules like javax.activation, javax.xml.bind, and others central to many applications. Ignoring these deprecations can lead to compatibility issues and security vulnerabilities down the line. Understanding the reasons behind the deprecation and the available alternatives is the first step towards a successful migration.

The primary driver for these deprecations is the transition to Jakarta EE, the open-source successor to Java EE. Jakarta EE offers a more modern and evolving platform for enterprise Java development. This shift necessitates replacing the older Java EE dependencies with their Jakarta EE counterparts.

Key Replacements for Deprecated Modules

Here’s a breakdown of some commonly deprecated JPMS modules and their Jakarta EE replacements:

javax.activation: Replace with jakarta.activation.
javax.xml.bind: Replace with jakarta.xml.bind-api.
javax.annotation: Replace with jakarta.annotation-api.

It’s crucial to ensure that all dependent libraries are also compatible with the new Jakarta EE versions. Inconsistencies in library versions can lead to runtime errors. Thoroughly testing your application after implementing these changes is essential to identify and resolve any integration issues.

For instance, if you’re using a library that still depends on javax.xml.bind, you might encounter conflicts. In such cases, consider upgrading the library to a version compatible with jakarta.xml.bind-api. If no compatible version is available, exploring alternative libraries that align with Jakarta EE might be necessary.

Implementing the Replacements

The migration process typically involves updating your project’s dependencies. This may involve modifying your build tools (Maven or Gradle) to include the new Jakarta EE dependencies and remove the deprecated ones.

Update your dependency management file (e.g., pom.xml for Maven). Remove the deprecated dependencies and add the corresponding Jakarta EE artifacts.
Refactor your code to use the new package names (e.g., change imports from javax. to jakarta.).
Thoroughly test your application to ensure all functionalities are working correctly with the new dependencies.

Consider using a robust testing framework to cover various scenarios and ensure a smooth transition. Automated tests can significantly reduce the risk of introducing regressions during the migration process.

For specific migration challenges, consult the official Jakarta EE documentation and community forums. These resources offer valuable insights and solutions for common issues encountered during the transition.

Best Practices for a Smooth Migration

Careful planning and execution are crucial for a successful migration. Start by creating a comprehensive inventory of all affected dependencies in your project. This helps prioritize the replacements and minimize disruptions.

Maintain consistent library versions to avoid conflicts.
Implement thorough testing at each stage of the migration.

Leveraging automated testing tools can streamline the process and identify potential issues early on. Furthermore, maintaining consistent library versions across your project helps prevent compatibility problems.

Learn more about migrating to Jakarta EE on the official website: Jakarta EE.

For deeper insights into JPMS, refer to the official documentation: JPMS Documentation.

Check out this helpful resource on dependency management: Maven.

A well-structured migration plan that includes thorough testing and version control can significantly reduce the risks and ensure a smooth transition.

Learn more about dependency injection.Future-Proofing Your Java Applications

Staying up-to-date with the latest Java and Jakarta EE versions is essential for maintaining secure and performant applications. Regularly reviewing your dependencies and proactively addressing deprecations ensures your application remains compatible with future Java releases.

Embrace the evolving Java ecosystem by adopting a proactive approach to dependency management and staying informed about the latest changes and best practices. This will ensure your applications remain robust, secure, and ready for the future.

FAQ

Q: What happens if I don’t migrate from the deprecated modules?

A: While your application might continue to function in the short term, it becomes increasingly vulnerable to security risks and compatibility issues. Future Java updates may remove the deprecated modules entirely, leading to application failures.

Successfully migrating from deprecated JPMS modules to Jakarta EE equivalents is crucial for the long-term health and security of your Java applications. By understanding the replacements, following best practices, and implementing thorough testing, you can ensure a seamless transition and a more robust, future-proof application. Start planning your migration today to avoid potential issues and leverage the benefits of the modern Jakarta EE platform. Dive deeper into specific migration scenarios and explore further resources available within the Jakarta EE community to gain a comprehensive understanding and tackle any challenges you might encounter. Remember, a well-planned migration is an investment in the future of your Java projects.

Question & Answer :
Java 9 deprecated six modules that contain Java EE APIs and they are going to be removed soon:

java.activation with javax.activation package
java.corba with javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.* packages
java.transaction with javax.transaction package
java.xml.bind with all javax.xml.bind.* packages
java.xml.ws with javax.jws, javax.jws.soap, javax.xml.soap, and all javax.xml.ws.* packages
java.xml.ws.annotation with javax.annotation package

Which maintained third-party artifacts provide those APIs? It doesn’t matter how well they provide those APIs or which other features they have to offer - all that matters is, are they a drop-in replacement for these modules/packages?

To make it easier to collect knoweldge, I answered with what I know so far and made the answer a community wiki. I hope people will extend it instead of writing their own answers.

Before you vote to close:

Yes, there are already some questions on individual modules and an answer to this question would of course duplicate that information. But AFAIK there is no single point to learn about all of these, which I think has a lot of value.
Questions asking for library recommendations are usually considered off-topic, because “they tend to attract opinionated answers and spam”, but I don’t think that applies here. The set of valid libraries is clearly delineated: They have to implement a specific standard. Beyond that nothing else matters, so I don’t see much risk for opinion and spam.

Instead of using the deprecated Java EE modules, use the following artifacts.

JAF (java.activation)

JavaBeans Activation Framework (now Jakarta Activation) is a standalone technology (available on Maven Central):

<dependency> <groupId>com.sun.activation</groupId> <artifactId>jakarta.activation</artifactId> <version>1.2.2</version> </dependency>

(Source)

CORBA (java.corba)

From JEP 320:

There will not be a standalone version of CORBA unless third parties take over maintenance of the CORBA APIs, ORB implementation, CosNaming provider, etc. Third party maintenance is possible because the Java SE Platform endorses independent implementations of CORBA. In contrast, the API for RMI-IIOP is defined and implemented solely within Java SE. There will not be a standalone version of RMI-IIOP unless a dedicated JSR is started to maintain it, or stewardship of the API is taken over by the Eclipse Foundation (the transition of stewardship of Java EE from the JCP to the Eclipse Foundation includes GlassFish and its implementation of CORBA and RMI-IIOP).

JTA (java.transaction)

Stand alone version:

<dependency> <groupId>jakarta.transaction</groupId> <artifactId>jakarta.transaction-api</artifactId> <version>1.3.3</version> </dependency>

(Source)

JAXB (java.xml.bind)

Since Java EE was rebranded to Jakarta EE, JAXB is now provided by new artifacts:

<!-- API --> <dependency> <groupId>jakarta.xml.bind</groupId> <artifactId>jakarta.xml.bind-api</artifactId> <version>2.3.3</version> </dependency> <!-- Runtime --> <dependency> <groupId>com.sun.xml.bind</groupId> <artifactId>jaxb-impl</artifactId> <version>2.3.3</version> <scope>runtime</scope> </dependency> <!-- Alternative runtime --> <dependency> <groupId>org.glassfish.jaxb</groupId> <artifactId>jaxb-runtime</artifactId> <version>2.3.3</version> <scope>runtime</scope> </dependency>

JAXB Reference Implementation page.

The alternative runtime was brought up by @Abhijit Sarkar since com.sun.xml.bind:jaxb-impl has been deprecated.

schemagen and xjc can be downloaded from there too as part of a standalone JAXB distribution.

JAX-WS (java.xml.ws)

Reference implementation:

<!-- API --> <dependency> <groupId>jakarta.xml.ws</groupId> <artifactId>jakarta.xml.ws-api</artifactId> <version>2.3.3</version> </dependency> <!-- Runtime --> <dependency> <groupId>com.sun.xml.ws</groupId> <artifactId>jaxws-rt</artifactId> <version>2.3.3</version> </dependency>

Standalone distribution download (contains wsgen and wsimport).

Common Annotations (java.xml.ws.annotation)

Java Commons Annotations (available on Maven Central):

<dependency> <groupId>jakarta.annotation</groupId> <artifactId>jakarta.annotation-api</artifactId> <version>1.3.5</version> </dependency>

(Source)