JEP 320：删除 Java EE 和 CORBA 模块

概括

从 Java SE 平台和 JDK 中删除 Java EE 和 CORBA 模块。这些模块在 Java SE 9 中已弃用，并声明打算在未来版本中删除它们。

动机

Java SE 6包含一个完整的 Web 服务堆栈，以方便 Java 开发人员。该堆栈由最初 为 Java EE 平台开发的四种技术组成： JAX-WS（用于基于 XML 的 Web 服务的 Java API）、JAXB（用于 XML 绑定的 Java 架构）、JAF（JavaBeans 激活框架）和通用注释。在包含时，Java SE 中的版本与 Java EE 中的版本相同，除了 Java SE 在通用注释中删除了涉及 Java EE 安全模型的包之外。然而，随着时间的推移，Java EE 中的版本不断演变，这导致了 Java SE 中的版本出现了困难：

• 这些技术获得了与 Java SE 无关的功能。例如，Common Annotations 在 Java EE 6 中添加了一个包，涉及 Java EE 容器中的数据源。这使得有必要定期对 Java EE 版本进行快照和子集化，这对于 JDK 工程师来说非常耗时，并且让开发人员感到困惑。

• 这些技术由 java.net 上的上游项目以及后来的GitHub上的上游项目维护。由于必须将 OpenJDK 存储库中的 Java SE 版本与上游存储库中的 Java EE 版本同步，这导致维护出现问题。

• 开发人员可以从上游项目获取技术的独立版本，并通过认可标准覆盖机制进行部署。这种长期存在的机制允许独立版本安全地覆盖 Java SE 版本。不幸的是，它在实践中并未得到广泛使用，开发人员转而使用临时机制来部署独立版本，例如将它们添加到 JDK 的引导类路径中，或者只是将它们放在类路径中并希望生成的拆分包能够不会造成问题。

由于 Java EE 技术的独立版本可以从第三方站点（例如 Maven Central）轻松获得，因此 Java SE 平台或 JDK 不需要包含它们。

Java SE 包含方便开发人员的技术的另一个案例可以追溯到 1998 年。在 Ken Cavanaugh 的杰出领导下，Java SE通过在 编译器。然而，随着时间的推移，对 CORBA 的支持出现了问题：idlj``rmic

• 由于 CORBA 是在 Java Community Process 之外发展的“认可标准”，因此类似于 Web 服务的注释适用于 JDK 中的 CORBA 维护以及安全地覆盖 JDK 的 CORBA 实现的能力。将 JDK 中的 ORB 与 Java EE 应用程序服务器中的 ORB 同步是不现实的。

• 人们对使用 Java 中的 CORBA 开发现代应用程序没有太大兴趣。此外，Java EE 8 将 CORBA、RMI-IIOP 和 JavaIDL 列为“建议可选”，表明将来可能会放弃对这些技术的必要支持。

由于维护 CORBA 支持的成本超过了收益，因此 Java SE 平台或 JDK 没有必要包含它。

最后，自 Java SE 1.3 起，Java SE 包含了JTA （Java Transaction API）的子集，以及自 Java SE 5.0 起的用于扩展事务的 J2EE 活动服务（J2EE Activity Service）的子集。

JTA 由两个包组成，它们扮演不同的角色并应得到不同的对待：

• 该javax.transaction.xa包支持 JDBC 中的 XA 事务。这个“ XA 包java.sql”与 Java SE 9 中的模块中的 JDBC 位于同一位置。由于该java.sql模块不可升级，因此独立版本的 JTA 不可能覆盖 Java SE 版本的 XA 包，但这是由于 XA 包已经稳定多年，并且 Java SE 版本与 Java EE 版本相同，因此通常可以被应用程序接受。为了便于维护，Java SE 中的 XA 包将来可能会移动到不同的不可升级模块，但作为架构问题，它将长期与 JDBC 一起保留在 Java SE 中，并且不会再引起人们的兴趣。这个JEP。

• 该javax.transaction包定义了通用事务管理 API。该包的 Java EE 版本始终超出了 Java SE 的范围，并且以与 Java SE 无关的方式发展。例如，JTA 在 Java EE 7 中添加了与 CDI 相关的类型。javax.transactionJava SE 定义的子集支持与 CORBA 事务服务的互操作。这个“ CORBA互操作包”存在于Java SE 9中它自己的java.transaction模块中。但是，Java SE版本通常不被使用CORBA事务服务的应用程序所接受，因此它们通常用Java EE版本覆盖它。

J2EE 活动服务定义了通用中间件 API。它自 2006 年以来就没有更新过，并且不是 Java EE 平台的一部分。它与此 JEP 相关只是因为 Java SE 包含其包之一的子集，javax.activity用于与 CORBA 事务服务的互操作。这个“活动包”存在于java.corbaJava SE 9的模块中。

如果 Java SE 平台或 JDK 中没有 CORBA 支持，则无法包含来自 JTA 的 CORBA 互操作包或来自 J2EE 活动服务的活动包。

描述

在 Java SE 9 中，包含 Java EE 和 CORBA 技术的 Java SE 模块被注释为已弃用以进行删除，表明打算在未来版本中删除它们：

• java.xml.ws（JAX-WS，加上相关技术SAAJ和Web 服务元数据）
• java.xml.bind（日本航空航天局）
• java.activation（日本空军）
• java.xml.ws.annotation（常用注解）
• java.corba（CORBA）
• java.transaction（日本交通局）

Java SE 9 中的相关模块也已弃用并删除：

• java.se.ee（上述六个模块的聚合器模块）
• jdk.xml.ws（JAX-WS 工具）
• jdk.xml.bind（JAXB 工具）

由于弃用删除模块只会导致编译时警告，因此 JDK 9 采取了更稳健的步骤，让开发人员为在未来版本中实际删除这些模块做好准备：在 JDK 运行时映像中编译或运行代码时，不会解析这些模块。类路径。这使得 JDK 9 上的开发人员可以在类路径上部署独立版本的 Java EE 和 CORBA 技术，就像在 JDK 8 上一样。或者，JDK 9 上的开发人员可以--add-modules在命令行上使用来解析 JDK 运行时映像中的模块。

在 Java SE 11 中，上面列出的九个模块将被删除：

• 他们的源代码将从 OpenJDK 存储库中删除。
• 它们的类不会存在于 JDK 运行时映像中。
• 他们的工具将不再可用：
  • wsgen和wsimport（来自jdk.xml.ws）
  • schemagen和xjc（来自jdk.xml.bind）
  • idlj、orbd、servertool和tnamesrv（来自java.corba）
• JNDICosNaming提供程序（来自java.corba）将不再可用。
• 没有任何命令行标志能够像--add-modulesJDK 9 那样启用它们。

编译rmic器将被更新以删除-idl和-iiop选项。因此，rmic将不再能够生成 IDL 或 IIOP 存根和连接类。

JDK 文档和手册页将更新，以删除对这些模块和工具的任何引用，并指示更改rmic。

测试

所有使用 Java EE 或 CORBA API 的 JDK、JCK 和 SQE 测试都将被删除。

风险和假设

Java EE 模块

删除 Java EE 模块的风险在于，如果应用程序依赖 JDK 中对 Java EE API 和工具的“开箱即用”支持，则应用程序将无法编译或运行。从 JDK 6、7 或 8 迁移到 JDK 9 或更高版本时，这些应用程序将遇到二进制和源不兼容的情况。一般来说，这些应用程序分为两类之一：

1. 在 Java EE 应用程序服务器外部操作 Web 服务和 XML 的独立程序。

2. 与 Web 服务或 XML 没有连接，但依赖 Java EE API 中的各个类来实现通用功能的应用程序。例如，某些应用程序依赖 JAXB 不是为了 XML 绑定，而是为了类提供的 Base64 支持javax.xml.bind.DatatypeConverter。 （从历史上看，该类是比 类更好的选择，尽管Java SE 8 中引入的sun.misc.Base64{Encoder,Decoder}类更好。 ）作为另一个示例，某些应用程序依赖于其类型与 JAX-WS 位于同一位置的注释。在 JDK 9 中。（应用程序可以选择依赖Java SE 9 中引入的类型。）。java.util.Base64``@Generated``javax.annotation.Generated``javax.annotation.processing.Generated

删除 Java EE 模块的另一个风险是，已经从 JDK 6、7 或 8 迁移到 JDK 9 的应用程序如果使用命令行标志--add-modules java.se.ee、--add-modules java.xml.bind等，将无法启动。

该提案假设希望在最新 JDK 上编译或运行应用程序的开发人员可以找到并部署 Java EE 技术的替代版本。 JAX-WS 和 JAXB 的参考实现 (RI) 是一个很好的起点，因为它们完全替代了JDK 9 中的java.xml.ws和java.xml.bind模块。RI 可作为 Maven 工件使用：（请注意，它们必须部署在类路径上）

• com.sun.xml.ws ：jaxws-ri（JAX-WS，加上 SAAJ 和 Web 服务元数据）
• com.sun.xml.bind ：jaxb-ri (JAXB)

JAX-WS 和 JAXB 的工具也可作为 Maven 工件使用：

• wsgen和wsimport：com.sun.xml.ws ： jaxws-tools，加上工具脚本
• schemagen和xjc：com.sun.xml.bind ： jaxb-jxc和com.sun.xml.bind ： jaxb-xjc，以及工具脚本

还有一些 Maven 工件仅包含 Java EE 技术的 API：

• javax.xml.ws：jaxws-api（JAX-WS，加上javax.xml.soap：用于 SAAJ 的 javax.xml.soap-api 和javax.xml：用于 Web 服务元数据的 webservices-api）
• javax.xml.bind ：jaxb-api (JAXB)
• javax.activation ：javax.activation-api (JAF)
• javax.annotation ：javax.annotation-api（常用注释）

实现此 JEP 后，这些 API JAR 文件可以部署在类路径上，就像在 JDK 8 和 9 上一样。它们也可以部署在模块路径上，以便模块化应用程序可以通过指令依赖它们requires：

• JAX-WS、JAXB 和 SAAJ 的 API JAR 文件是名为java.xml.ws、java.xml.bind和的显式模块java.xml.soap。

• Web 服务元数据的 API JAR 文件是一个名为 的自动模块webservices.api。 （此名称源自 JAR 文件名，因为 JAR 清单尚未使用属性进行更新Automatic-Module-Name。）

• JAF 和通用注释的 API JAR 文件是名为java.activation和 的自动模块java.annotation。 （这些名称由Automatic-Module-NameJAR 清单中的属性指定。）

在 JDK 9 上，描述中提到的所有模块（java.se.ee聚合器除外）都是可升级的。这意味着使用--add-modules java.xml.bindetc 的 JDK 9 开发人员可以选择依赖 JDK 运行时映像中的 Java EE 模块，或者通过在_升级模块路径_上部署 API JAR 文件来覆盖它们。注意这里涉及的是_升级模块路径_而不是模块路径；即使使用了 etc，在 JDK 9 上的模块路径上部署 API JAR 文件也没有任何效果，--add-modules java.xml.bind因为 JDK 运行时映像中的 Java EE 模块优先于模块路径上具有相同名称的模块。实现此 JEP 后，Java EE 模块将不会出现在 JDK 运行时映像中，因此开发人员可以在模块路径上部署 API JAR 文件。

CORBA 和 JTA 模块

删除该模块的风险java.corba是：

1. 如果 CORBA 实现仅包含“认可的”CORBA API的一个子集并期望 JDK 提供其余部分，则它们将无法编译或运行。

2. 使用 RMI-IIOP 的应用程序和 CORBA 实现将无法编译或运行。 RMI-IIOP 包（javax.rmi和javax.rmi.CORBA）位于模块中并与其中的 CORBA 实现相关联，因此一旦删除，java.corbaJava SE 中将不再支持 RMI-IIOP 。java.corba

3. 使用该javax.activity包的应用程序和 CORBA 实现将无法编译或运行。该包位于模块中，并与其中的 CORBA 实现相关联，因此一旦删除，java.corbaJava SE 中将不再支持。java.corba

除非第三方接管 CORBA API、ORB 实现、CosNaming 提供者等的维护，否则不会有独立版本的 CORBA。第三方维护是可能的，因为 Java SE 平台支持 CORBA 的独立实现。相比之下，RMI-IIOP 的 API 仅在 Java SE 中定义和实现。除非启动专门的 JSR 来维护它，或者 API 的管理权由 Eclipse 基金会接管，否则不会有 RMI-IIOP 的独立版本。 Java EE 管理权从 JCP 到 Eclipse 基金会的过渡包括CORBA 和 RMI-IIOP 的 GlassFish 实现。最后，J2EE 活动服务没有独立版本。

JTA 的独立版本可用作 Maven 工件javax.transaction ： javax.transaction-api。截至 2017 年 11 月，此 JAR 文件代表 JTA 1.2，其中包含 XA 包和 CORBA 互操作包。 2018 年初，JTA 1.3 将被定义为仅包含 CORBA 互操作包； JAR 文件将相应更新。 JTA 1.2 和 JTA 1.3 的 JAR 文件可以按如下方式部署：

• JTA 1.2 的 JAR 文件可以部署在类路径上。 （JAR 文件中的 XA 包将被忽略，优先使用java.sql模块中的 XA 包。JAR 文件中的 CORBA 互操作包优先于模块中的包使用java.transaction，这在 JDK 9 上默认不解析。如果在 JDK 9 上使用--add-modules java.se.ee或--add-modules java.transaction，则 JAR 文件中的 CORBA 互操作包将被忽略，而使用模块中的包java.transaction。）

• JTA 1.2 的 JAR 文件可能不会部署在模块路径上。 （它将被视为包含 XA 包的自动模块，但该包会与模块中的 XA 包冲突java.sql。）

• JTA 1.3 的 JAR 文件可以部署在类路径上。 （JAR文件中的CORBA互操作包优先于java.transaction模块中的包，在JDK 9中默认不解析。）

• JTA 1.3 的 JAR 文件可以部署在模块路径上并用作名为 的自动模块java.transaction。