Keywords: Java 9 | JPMS | Jakarta EE | module migration | third-party dependencies
Abstract: This article provides a comprehensive analysis of the alternatives for the six deprecated Java EE modules in Java 9, including java.activation, java.corba, java.transaction, java.xml.bind, java.xml.ws, and java.xml.ws.annotation. Based on community best practices, it offers specific Maven dependency configurations and explains the transition from Java EE to Jakarta EE. By examining the functionality and replacement implementations of each module, it provides clear migration paths for developers to ensure compatibility in the Java Platform Module System (JPMS) environment.
With the release of Java 9, the Java Platform Module System (JPMS) deprecated six modules containing Java EE APIs, which are scheduled for removal in future versions. This change necessitates that developers seek third-party alternatives to maintain existing functionality. Based on community consensus and best practices, this article systematically introduces replacement implementations for these deprecated modules, focusing on relevant projects within the Jakarta EE ecosystem.
Alternative for JavaBeans Activation Framework (java.activation)
The JavaBeans Activation Framework (JAF), now known as Jakarta Activation, has been removed from Java SE and is maintained as a standalone project. Developers can integrate its implementation via Maven dependencies, such as com.sun.activation:jakarta.activation:1.2.2. This alternative provides the same APIs as the original javax.activation package, ensuring backward compatibility. During migration, only dependency configurations need to be updated, without modifying existing code logic.
Status of CORBA Module (java.corba)
According to JEP 320, the CORBA module (including javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.* packages) will not have a standalone replacement unless third parties take over its maintenance. Currently, the Eclipse Foundation provides implementations through the GlassFish project, but developers should note that RMI-IIOP components may lack direct alternatives. Therefore, for applications relying on CORBA, it is advisable to evaluate the necessity of migrating to modern communication protocols.
Alternative for Java Transaction API (java.transaction)
The standalone version of the Java Transaction API (JTA) can be obtained via jakarta.transaction:jakarta.transaction-api:1.3.3. This implementation is maintained by the Eclipse EE4J project and is fully compatible with the original javax.transaction package. During integration, developers should ensure that transaction manager configurations align with the new dependencies to avoid runtime errors.
Migration Path for JAXB (java.xml.bind)
With the transition from Java EE to Jakarta EE, alternatives for JAXB include both API and runtime components. The API dependency is jakarta.xml.bind:jakarta.xml.bind-api:2.3.3, while the runtime can be com.sun.xml.bind:jaxb-impl:2.3.3 or org.glassfish.jaxb:jaxb-runtime:2.3.3. Notably, jaxb-impl has been marked as deprecated, so jaxb-runtime is recommended. Additionally, tools such as schemagen and xjc can be downloaded separately from the JAXB Reference Implementation page.
Alternative Implementation for JAX-WS (java.xml.ws)
The reference implementation for JAX-WS provides a complete alternative, including the API dependency jakarta.xml.ws:jakarta.xml.ws-api:2.3.3 and the runtime dependency com.sun.xml.ws:jaxws-rt:2.3.3. Developers can also download standalone distributions from the Metro JAX-WS releases page, which include wsgen and wsimport tools. This migration ensures that web service-related functionalities continue to operate after the removal of the java.xml.ws module.
Update for Common Annotations (java.xml.ws.annotation)
The alternative for the Common Annotations module can be implemented via jakarta.annotation:jakarta.annotation-api:1.3.5, a project maintained by Eclipse EE4J. This dependency offers the same functionality as the original javax.annotation package, supporting annotation-driven development patterns. During migration, developers must update all relevant import statements to reflect the namespace change from javax to jakarta.
In summary, starting from Java 9, developers should gradually migrate deprecated Java EE modules to third-party implementations under Jakarta EE. This process involves not only updating dependency management but may also require minor code adjustments, particularly for package name changes. By adopting the alternatives recommended in this article, applications can maintain compatibility and stability in future Java versions.