News

JDK 11 in Release Candidate Phase

• By John K. Waters
• August 29, 2018

JDK 11, the latest reference implementation of the Java SE Platform, is now in the Release Candidate Phase, and if Oracle's new rapid release cadence holds (as it did between JDK 9 and 10), we should be seeing it move into general availability on or about Sept. 25.

Mark Reinhold, chief architect of Oracle's Java Platform Group, who owns JEP 3, the Java Enhancement Proposal governing the JDK Release Process, announced the new phase in mid-August on the JDK message board with little fanfare, but it's a significant release for a number of reasons, not the least of which is the removal of the Java EE and CORBA Modules from the Java SE Platform and the JDK.

Both modules were deprecated in Java SE 9 per JEP 277, and JEP 320 ("Remove the Java EE and CORBA Modules") was created back in October 2017, so there are no surprises here, but the faster release cadence might make the change seem sudden to some developers.

The reasons for dropping these modules are fairly straightforward. The JEP offers a detailed argument, but the reasons might be boiled down to two: Stand-alone versions of the Java EE technologies are readily available from third-party sites, such as Maven Central, so there's no need to include them in the Java SE Platform or the JDK, and let's face it, no one builds modern applications with CORBA in Java.

JEP 320 removes the following nine modules that contain Java EE and CORBA technologies:

• java.xml.ws (JAX-WS, plus the related technologies SAAJ and Web Services Metadata)
• java.xml.bind (JAXB)
• java.activation (JAF)
• java.xml.ws.annotation (Common Annotations)
• java.corba (CORBA)
• java.transaction (JTA)
• java.se.ee (Aggregator module for the six modules above)
• jdk.xml.ws (Tools for JAX-WS)
• jdk.xml.bind (Tools for JAXB)

There are some risks here, which were acknowledged in the JEP 320 documentation.

"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. These applications will experience binary and source incompatibilities when migrating from JDK 6, 7, or 8, to JDK 9 or a later release."

The at-risk apps fall into two categories: Standalone programs that manipulate Web Services and XML, outside a Java EE application server; applications that have no connection to Web Services or XML, but rely on individual classes in the Java EE APIs for general-purpose functionality.

Another risk cited on the Web site: Apps already migrated from JDK 6, 7, or 8, to JDK 9 will not start if they use the command line flag --add-modules java.se.ee, --add-modules java.xml.bind, and so on.

"This proposal [JEP 320] 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," the Web site states. "The Reference Implementations (RIs) of JAX-WS and JAXB are a good starting point, because they are complete replacements for the java.xml.ws and java.xml.bind modules in JDK 9.

Also, removing the CORBA module could mean that CORBA implementations won't compile or run if they include only a subset of the "endorsed" CORBA APIs, and expect the JDK to provide the rest. Apps and CORBA implementations using the Java Remote Message Invocation over the Internet Inter-Orb Protocol (RMI-IIOP) won't compile or run. And apps and CORBA implementations the use the javax.activity package will not compile or run.