JDK 11: End of the road for Java EE modules
© Shutterstock / Ercken
It’s been a long time coming! The Java SE modules that contain Java EE technologies have been annotated as deprecated for removal in JDK 9, so this is hardly news. However, removing the Java EE modules is not without risks.
Time to take a trip down memory lane: “Java SE 6 included a full Web Services stack for the convenience of Java developers. The stack consisted of four technologies that were originally developed for the Java EE Platform: JAX-WS (Java API for XML-Based Web Services), JAXB (Java Architecture for XML Binding), JAF (the JavaBeans Activation Framework), and Common Annotations,” according to JEP 320: Remove the Java EE and CORBA Modules created by Lance Andersen.
The versions in Java SE were exactly the same as the ones in Java EE, with only one exception: Java SE dropped a package in Common Annotations that concerned the Java EE security model. As time passed, “the versions in Java EE evolved, which led to difficulties for the versions in Java SE,” including the fact that the technologies gained features that were not relevant to Java SE.
Since standalone versions of the Java EE technologies are readily available from third-party sites, such as Maven Central, there is no need for the Java SE Platform or the JDK to include them.
Step 1: Deprecate Java EE modules ✓
The Java SE modules that contain Java EE technologies have been annotated as deprecated for removal in JDK 9, which already indicated the intent to remove them in a future release [That “future release” could be JDK 11]:
java.xml.ws(JAX-WS, plus the related technologies SAAJ and Web Services Metadata)
Related modules in Java SE 9 are also deprecated for removal:
java.se.ee(Aggregator module for the six modules above)
jdk.xml.ws(Tools for JAX-WS)
jdk.xml.bind(Tools for JAXB)
“Since deprecating modules for removal merely causes compile-time warnings, JDK 9 took a more robust step to prepare developers for the actual removal of these modules in a future release: The modules are not resolved in JDK 9 when code on the class path is compiled or run,” Andersen explained.
Therefore, developers on JDK 9 can deploy standalone versions of the Java EE and CORBA technologies on the class path or use the
--add-modules flag on the command line to resolve the modules in the JDK runtime image.
JEP 320 will remove these nine modules:
- Their source code will be deleted from the OpenJDK repository.
- Their classes will not exist in the JDK runtime image.
- Their tools will no longer be available:
- The JNDI
java.corba) will no longer be available.
- No command line flag will be capable of enabling them, as
--add-modulesdoes on JDK 9.
If you want to read more about these changes, check out Alan Bateman’s message to the OpenJDK mailing list.
Risks of removing the Java EE modules
“The risk of removing the Java EE modules is that applications will not compile or run if they rely on ‘out of the box’ support in the JDK for Java EE APIs and tools,” according to Andersen. “These applications will experience binary and source incompatibilities when migrating from JDK 6, 7, or 8, to JDK 9 or a later release.”
Furthermore, applications which already migrated from JDK 6, 7, or 8, to JDK 9, won’t start if they use the command line flag
--add-modules java.xml.bind, etc.
This proposal assumes that developers who wish to compile or run applications on the latest JDK can find and deploy alternate versions of the Java EE technologies.
Read more about this JEP candidate here.