Ready to say goodbye?

JDK 11: End of the road for Java EE modules

Gabriela Motroc
Java EE

© 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.

Lance Andersen 

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]:

  • (JAX-WS, plus the related technologies SAAJ and Web Services Metadata)
  • java.xml.bind (JAXB)
  • java.activation (JAF)
  • (Common Annotations)
  • java.corba (CORBA)
  • java.transaction (JTA)

Related modules in Java SE 9 are also deprecated for removal:

  • (Aggregator module for the six modules above)
  • (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 releaseThe 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.

SEE ALSO: JDK 10: These are the features that made the cut

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:
    • wsgen and wsimport (from
    • schemagen and xjc (from jdk.xml.bind)
    • idljorbdservertool, and tnamesrv (from java.corba)
  • The JNDI CosNaming provider (from 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

Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Inline Feedbacks
View all comments
Red Boy
Red Boy
3 years ago

Agreed, that java developers, organization must be moving towards agility fast pace development, as Oracle is moving faster, stopping support& downloads very frequently. See here
Reply to  Red Boy
3 years ago

These changes reminds me of the old-school EJB . They were introduced so that Java become “elite” and not fall into “commodity trap”, hence they have difficult learning curve, bring much more complexity rather than convenience (i.e. make things more difficult for development instead of make them easier) .

Java 9 already has over-engineering, Java 11 makes it worse. Oracle will be new Sun.

Docker Guy
Docker Guy
3 years ago

Those having to maintain a lot of legacy code are being burned by this. The solution of finding libraries from many alternative sources creates risk. Building a separate library from the EE project of what had been yanked from SE would have resolved this. This decision compounds problems created by an earlier bad decision and is pushing people away from Java.