跳到主要内容

JEP 320: Remove the Java EE and CORBA Modules

Summary​

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

Motivation​

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. 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 evolved, which led to difficulties for the versions in Java SE:

  • The technologies gained features that were not relevant to Java SE. For example, Common Annotations added a package in Java EE 6 that concerned data sources in a Java EE container. This made it necessary to periodically snapshot and subset the Java EE versions, which was time consuming for JDK engineers and confusing for developers.

  • The technologies were maintained by upstream projects on java.net and later on GitHub. This made maintenance problematic due to having to sync the Java SE versions in OpenJDK repositories with the Java EE versions in upstream repositories.

  • It was possible for developers to obtain standalone versions of the technologies from the upstream projects and deploy them via the Endorsed Standards Override Mechanism. This longstanding mechanism allowed standalone versions to safely override the Java SE versions. Unfortunately, it was not widely used in practice, and developers instead used ad-hoc mechanisms to deploy standalone versions, such as prepending them to the JDK's bootstrap class path, or simply placing them on the class path and hoping that the resulting split packages would not cause problems.

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 CORBA is an "Endorsed Standard" that evolves outside the Java Community Process, comments similar to those for Web Services apply to the maintenance of CORBA in the JDK and to the ability to safely override the JDK's CORBA implementation. There is no realistic prospect of synchronizing the ORB in the JDK with the ORBs in Java EE application servers.

  • There is no significant interest in developing modern applications with CORBA in Java. Furthermore, Java EE 8 lists CORBA, RMI-IIOP, and JavaIDL as "Proposed Optional", indicating that required support for these technologies may be dropped in future.

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 Java SE 1.3 and a subset of the J2EE Activity Service for Extended Transactions (J2EE Activity Service) since Java SE 5.0.

JTA consists of two packages that play different roles and deserve different treatment:

  • The javax.transaction.xa package supports XA transactions in JDBC. This "XA package" is co-located with JDBC in the java.sql module in Java SE 9. Because the java.sql module is not upgradeable, it is not possible for a standalone version of JTA to override the Java SE version of the XA package, but this is generally acceptable to applications because the XA package has been stable for many years and the Java SE version is identical to the Java EE version. For ease of maintenance, the XA package in Java SE may be moved to a different non-upgradeable module in the future, but as an architectural matter it will remain in Java SE alongside JDBC for the long term, and is of no further interest to this JEP.

  • The javax.transaction package defines a general transaction management API. The Java EE version of this package was always beyond the scope of Java SE and has evolved in ways that are not relevant to Java SE. For example, JTA added types in Java EE 7 that concern CDI. The subset of javax.transaction defined by Java SE supports interoperation with CORBA transaction services. This "CORBA interop package" exists in its own java.transaction module in Java SE 9. However, the Java SE version is generally not acceptable to applications that use CORBA transaction services, so they usually override it with the Java EE version.

The J2EE Activity Service defines a generic middleware API. It has not been updated since 2006 and is not part of the Java EE Platform. It is relevant to this JEP only because Java SE includes a subset of one of its packages, javax.activity, for interoperation with CORBA transaction services. This "activity package" exists in the java.corba module in Java SE 9.

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

Description​

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

  • 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)

Related modules in Java SE 9 were 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 in the JDK runtime image were not resolved when compiling or running code on the class path. This allowed developers on JDK 9 to deploy standalone versions of the Java EE and CORBA technologies on the class path, just like on JDK 8. Alternatively, developers on JDK 9 could use --add-modules on the command line to resolve the modules in the JDK runtime image.

In Java SE 11, the nine modules that are listed above will be removed:

  • 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 jdk.xml.ws)
    • schemagen and xjc (from jdk.xml.bind)
    • idlj, orbd, servertool, 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-modules does on JDK 9.

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 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. 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 the class sun.misc.Base64{Encoder,Decoder}, though better still is the class java.util.Base64 that was 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 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 the latest JDK 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 class path)

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:

After this JEP is implemented these API JAR files may be deployed on the class path, just like on JDK 8 and 9. They may also be deployed on the module path so that modular applications can depend on them via the requires directive:

  • The API JAR files for JAX-WS, JAXB, and SAAJ are explicit modules called java.xml.ws, java.xml.bind, and java.xml.soap.

  • The API JAR file for Web Services Metadata is an automatic module called webservices.api. (This name is derived from the JAR filename, as the JAR manifest has not been updated with an Automatic-Module-Name attribute.)

  • The API JAR files for JAF and Common Annotations are automatic modules called java.activation and java.annotation. (These names are specified by the Automatic-Module-Name attribute in the JAR manifests.)

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 module path; deploying API JAR files on the module path 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 module path. After this JEP is implemented, the Java EE modules will not be present in the JDK runtime image, so developers can deploy API JAR files on the module path.

CORBA and JTA modules​

The risks of removing the java.corba module 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 (javax.rmi and javax.rmi.CORBA) are located in the java.corba module and tied to the CORBA implementation therein, so there will be no RMI-IIOP support in Java SE once java.corba is removed.

  3. Applications and CORBA implementations that use the javax.activity package will not compile or run. This package is located in the java.corba module and tied to the CORBA implementation therein, so there will be no support in Java SE 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 API for RMI-IIOP is defined and implemented solely within Java SE. There will not be a standalone version of RMI-IIOP unless a dedicated JSR is started to maintain it, or stewardship of the API is taken over by the Eclipse Foundation. The transition of stewardship of Java EE from the JCP to the Eclipse Foundation includes the GlassFish implementation of CORBA and RMI-IIOP. Finally, there is no standalone version of the J2EE Activity Service.

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:

  • The JAR file for JTA 1.2 may be deployed on the class path. (The XA package in the JAR file is ignored in favor of the XA package in the java.sql module. The CORBA interop package in the JAR file is used in preference to the package in the java.transaction module, which is not resolved by default on JDK 9. Note that if --add-modules java.se.ee or --add-modules java.transaction is used on JDK 9, then the CORBA interop package in the JAR file will be ignored in favor of the package in the java.transaction module.)

  • The JAR file for JTA 1.2 may not be deployed on the module path. (It would be treated as an automatic module that contains the XA package, but this package would conflict with the XA package in the java.sql module.)

  • The JAR file for JTA 1.3 may be deployed on the class path. (The CORBA interop package in the JAR file is used in preference to the package in the java.transaction module, which is not resolved by default in JDK 9.)

  • The JAR file for JTA 1.3 may be deployed on the module path and used as an automatic module called java.transaction.