JEP draft: Remove the Java EE and CORBA modules from Java SE and the JDK

OwnerLance Andersen
Created2017/10/11 18:36
Updated2017/11/20 14:01
TypeFeature
StatusSubmitted
Componentother-libs
ScopeSE
Discussionjdk dash dev at openjdk dot java dot net
EffortM
Priority2
Reviewed byAlan Bateman, Alex Buckley, Brian Goetz
Issue8189188

Summary

Remove the Java EE and CORBA modules from Java SE and the JDK. These modules were already deprecated in Java SE 9 with the specific intent to remove them in a future release.

Motivation

Java SE 6 included a full Web Services stack for the convenience of all 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 (JavaBeans Activation Framework), and Common Annotations. At the time of inclusion, the versions in Java SE were identical to the versions in Java EE, except for Java SE dropping a package in Common Annotations that concerned the Java EE security model. However, over time, the versions in Java EE were evolved, which led to difficulties for the versions in 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.

Another case of Java SE including technologies for developer convenience dates back to 1998. Under Ken Cavanaugh's distinguished leadership, Java SE embraced CORBA by shipping the OMG CORBA API, an ORB implementation, a CosNaming implementation, the idlj compiler, and support for IDL and IIOP in the rmic compiler. However, over time, support for CORBA became problematic:

Since the costs of maintaining CORBA support outweigh the benefits, there is no case for the Java SE Platform or the JDK to include it.

Finally, Java SE has included a subset of JTA (Java Transaction API) since JDK 1.3. JTA consists of two packages that play different roles and deserve different treatment:

Without CORBA support in the Java SE Platform or the JDK, there is no case for including the CORBA interop package from JTA.

Description

In Java SE 9, the Java SE modules that contain Java EE and CORBA technologies are annotated as deprecated for removal, indicating the intent to remove them in a future release:

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

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 classpath is compiled or run. This allows developers on JDK 9 to deploy standalone versions of the Java EE and CORBA technologies on the classpath, just like on JDK 8. Alternatively, developers on JDK 9 can use the --add-modules flag on the command line to resolve the modules in the JDK runtime image.

In JDK TBD, all nine modules above will be removed:

The rmic compiler will be updated to remove the -idl and -iiop options. Consequently, rmic will no longer be able to generate IDL or IIOP stubs and tie classes.

The JDK documentation and man pages will be updated to remove any references to these modules and tools, and to indicate the rmic changes.

Testing

All JDK, JCK, and SQE tests that exercise the Java EE or CORBA APIs will be removed.

Risks and Assumptions

Java EE modules

The risk of removing the Java EE modules in JDK TBD 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 TBD. Generally speaking, these applications fall into one of two categories:

  1. Standalone programs that manipulate Web Services and XML, outside of a Java EE application server.

  2. Applications that have no connection to Web Services or XML, but rely on individual classes in the Java EE APIs for general-purpose functionality. For example, some applications rely on JAXB not for XML binding, but rather, for the Base64 support offered by the class javax.xml.bind.DatatypeConverter. (Historically, this class was a better choice than sun.misc.Base64{Encoder,Decoder}, though better still is java.util.Base64 introduced in Java SE 8.) As another example, some applications rely on the @Generated annotation whose type, javax.annotation.Generated, is co-located with JAX-WS in JDK 9. (Applications may choose instead to rely on the type javax.annotation.processing.Generated that was introduced in Java SE 9.)

Another risk of removing the Java EE modules in JDK TBD is that applications which 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, etc.

This proposal assumes that developers who wish to compile or run applications on JDK TBD can find and deploy alternate versions of the Java EE technologies. 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. The RIs are available as Maven artifacts: (note that they must be deployed on the classpath)

The tools for JAX-WS and JAXB are also available as Maven artifacts:

There are also Maven artifacts that contain just the APIs of the Java EE technologies:

These API JAR files may be deployed on the classpath on JDK TBD, just like on JDK 8 and 9. They may also be deployed on the modulepath on JDK TBD so that modular applications can depend on them via the requires directive:

(On JDK 9, all the modules mentioned in the Description (except for the java.se.ee aggregator) are upgradeable. This means that developers on JDK 9 who use --add-modules java.xml.bind etc have the choice of either relying on the Java EE modules in the JDK runtime image, or overriding them by deploying API JAR files on the upgrade module path. Note the involvement of the upgrade module path rather than the modulepath; deploying API JAR files on the modulepath on JDK 9 has no effect, even when --add-modules java.xml.bind etc is used, because the Java EE modules in the JDK runtime image are preferred to modules with the same name on the modulepath. On JDK TBD, the Java EE modules are not present in the JDK runtime image, so developers can deploy API JAR files on the modulepath.)

CORBA and JTA modules

The risks of removing the java.corba module in JDK TBD are:

  1. CORBA implementations will not compile or run if they include only a subset of the "endorsed" CORBA APIs and expect the JDK to provide the remainder.

  2. Applications and CORBA implementations that use RMI-IIOP will not compile or run. The RMI-IIOP packages (principally javax.rmi.**) are located in the java.corba module and tied to the CORBA implementation therein, so there will be no RMI-IIOP support once java.corba is removed.

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 Java SE Platform does not endorse independent implementations of RMI-IIOP. The API for RMI-IIOP is defined and implemented solely within Java SE, akin to java.lang.String. Consequently, there will not be a standalone version of RMI-IIOP unless a dedicated JSR is started and the implementation is factored out of JDK 9's java.corba module.

A standalone version of JTA is available as the Maven artifact javax.transaction : javax.transaction-api. As of November 2017, this JAR file represents JTA 1.2, which consists of both the XA package and the CORBA interop package. In early 2018, JTA 1.3 will be defined to consist of just the CORBA interop package; the JAR file will be updated accordingly. The JAR files for JTA 1.2 and JTA 1.3 may be deployed as follows: