这篇冗长的文章讨论了Eclipse Foundation和Oracle之间关于命名空间和商标权的争议。

如果您在2017年错过了新闻，那么Oracle就会将Java EE规范捐赠给Eclipse基金会。这个决定在规范过程中进行了相当长时间的休眠，人们理所当然地怀疑Oracle对Java EE失去了战略兴趣。起初，Java EE和更广泛的Java社区很好地满足了捐赠规范的决定。如果没有Oracle放慢流程，那些参与Java EE的人可能会再次尝试关闭非标准化的API。直到今天，由于甲骨文和Eclipse基金会对捐赠的几个细节存在分歧，捐赠过程仍未完成。

在转换所有知识产权的同时，Oracle在规范的新家中使用其Java品牌时并不那么慷慨。当然，Java EE确实包含Oracle拥有的开源且受商标保护的平台的名称。这会在法律背景下产生问题：如果您授予第三方使用您的品牌名称，您将来有权限制它。更糟糕的是，当谈到有关您品牌的诉讼时，您可能会削弱您在法庭上的地位。随着甲骨文和谷歌多年来争论Java许可的历史，人们可以预见到品牌化将成为一个困难的讨论点。并且不假装对国际商标法有多少了解，有人告诉我更多参与者“使用它或失去它”对于理解这种分歧的一般格言是一个足够好的近似。因此，第一个结果是，规范从Java EE重命名为Jakarta EE，以避免利益冲突。

然而，新成立的雅加达EE社区的真正震惊还未到来。经过几个月的讨论捐赠手续，Eclipse基金会了解到它无法承担托管Java EE中定义的API的当前javax命名空间的所有权。相反，此命名空间现在计划为所有捐赠的API休眠。因此，任何将在Jakarta EE的规范过程中创建的新API都应该托管在新的命名空间中，以避免侵犯Oracle的商标。

在这一点上，澄清这意味着什么很重要。不禁止Jakarta EE和Eclipse Foundation使用javax命名空间或实现其API。也不会删除当前存在的API。但是，在新形成的Jakarta EE规范过程中创建或更新的任何API都需要存在于新的命名空间中，该命名空间最有可能模仿现有的命名空间，但使用jakarta作为其前缀而不是javax。例如，如果要将新方法添加到javax.servlet.Servlet接口，则下一版本的servlet规范需要发布名为jakarta.servlet.Servlet的新接口，而不是将此方法添加到现有API中。

我不是Java EE用户。我为什么要关心？

正如大多数人所知，Java平台正式分为两部分。第一部分是Java SE，其中所有API都在以java为前缀的包中定义。除此之外，Java EE还在javax命名空间中指定扩展API。这些API并不意味着特定的实现，而只是定义由不同Java EE兼容组件供应商实现的行为。

在这种情况下，Java EE是几个不依赖于彼此的API规范的总称。例如，Java消息传递规范（JMS）定义了用于与消息队列交互的API，而Java servlet规范定义了用于将调用分派给Web服务器的API。实际上，我所知道的Java EE应用程序运行时没有实现Java EE规范过程中定义的整个API。一些Java框架甚至专注于实现单一规范。例如，Jetty Web服务器仅实现Java servlet规范。因此，如果您通过Spring Boot使用Jetty，即使您没有直接与规范交互或认为自己是Java EE用户，您也正式成为Java EE的用户。

尽管存在这种形式上的区别，但即使您只编写了vanilla Java而没有包含任何外部依赖项，您也可能遇到过Java EE及其javax命名空间。这是因为选择的Java EE API与JVM的标准映像捆绑在一起。除了API之外，JVM还提供了此API的默认实现，以便用户无需任何额外工作即可轻松解决常见任务。例如，JAXP是一个Java EE规范，它定义了一个用于在Java中处理XML的API。由于XML处理是一项常见任务，特别是在面向企业的Java平台上，因此将其包含在内是一个合理的选择。对于JAXP，它假定的常见用法在今天仍然是事实，但其他JVM捆绑的Java EE规范并没有同样好的老化。例如，SOAP消息传递不再是大多数Java开发人员的首选，因此JVM捆绑的JAX-WS实现对于大多数用户来说已经变得非常重要。为了减少JVM的占用空间，并且在Java 9中引入了Java模块系统，一些Java EE API被移至已弃用的模块，这些模块计划在将来的版本中删除。当然，这并不意味着模块的API本身已被弃用。 JAX-WS仍然活跃并被许多人积极使用。但是由于这个模块被弃用，JAX-WS需要被那些想要在未来的Java版本中继续使用它的人添加为显式依赖。

在我们在虚拟化硬件上运行微服务的时代，减少JVM占用空间已成为演进JVM的明显目标。但是从基础JVM映像中删除Java EE API还有另一个优点。通过要求用户包含对Java EE API的显式依赖，升级Java运行时和Java EE不再捆绑在一起。在Java 8之前，管理这种版本的相互依赖性一直很乏味。如果您不控制要部署应用程序的JVM的确切版本，则尤其如此。在Java 8之前，JVM只允许您通过将JAR文件放入JVM的扩展文件夹来覆盖隐式Java EE依赖项。但是，当您与其他也会受到影响的Java进程共享JVM安装时，这当然是有问题的。此外，您仍然需要对正在使用的JVM安装进行一些控制。为了解决这个问题，默认情况下，Java模块系统不再解析已弃用的Java EE模块，这样可以在JVM中包含显式版本，尽管可以继续按需捆绑，同时还提供了一种激活旧版兼容性的简单方法。

为了使事情变得更加复杂，一小部分Java EE API以不允许简单分离的方式发展为Java SE。例如，JDBC规范分为“客户端”和“服务器端”需求，前者正式属于Java SE，后者则是Java EE的一部分。这种区别来自最初的Java哲学，其中人们将Java SE用于面向用户的桌面应用程序，而Java EE用于多个并发用户使用的服务器应用程序。本着这种精神，JDBC Connection接口例如在java.sql包中定义。毕竟，桌面用户当然可能想要连接到数据库。另一方面，JDBC DataSource接口在javax.sql包中定义，因为连接池仅被视为多线程服务器应用程序的要求。从今天的角度来看，这种分离当然不再有意义，但命名空间和形式上的区别在今天仍然存在。

当然，让JDBC API在由OpenJDK项目管理的Java SE和现在由Eclipse Foundation管理的Jakarta EE中单独发展是没有意义的。因此，并非Java EE规范的所有部分都捐赠给Eclipse，因此将为JDBC API保留javax.sql命名空间，该API现在被认为是仅Java SE的一部分。此类API保留的其他示例是JMX API，它严重依赖于本机JVM支持。当然，所有其他始终被认为是Java SE的一部分的API，例如最终在Java扩展名称空间中的Swing API，仍将保留在其原始包中。

那么向后兼容性怎么样？

需要记住的重要一点是，现在或将来，现有的javax API都不会消失。就个人而言，我还希望现在雅加达EE的一部分规范能够在未来许多年内支持javax命名空间。事实上，处理多个名称空间对于大多数Java EE实现来说并不是什么新鲜事，但它始终是一个需要处理的重要主题。例如，Hibernate库在逐渐用JPA规范定义的注释替换自己的注释时已经成功完成了类似的迁移。在另一个示例中，Spring框架支持与其本机注释并行的Java EE CDI规范。这样做，例如，可以通过使用javax.inject.Inject批注或Spring的本机Autowired批注来请求bean注入。一旦Inject注释转移到jakarta包，我就会期望Spring框架同时支持Java EE和Jakarta EE命名空间，因为我也期望它来自Java企业API的其他实现者。

由于Jakarta EE是Java EE的继承者，我不希望这种支持的实现或维护成本过高，因为应用服务器供应商可以简单地实现委托给现在过时的Java EE API的Jakarta EE包装器类。例如，通过定义类似于以下内容的包装类，可以在内部将Java EE servlet视为Jakarta EE servlet：

public class LegacyServlet implements jakarta.servlet.Servlet {

  private final javax.servlet.Servlet delegate;

  public LegacyServlet(javax.servlet.Servlet delegate) {

    this.delegate = delegate;

  }

  @Override

  public void service(jakarta.servlet.ServletRequest req, jakarta.servlet.ServletResponse resp) {

 delegate.service(new LegacyServletRequest(req), new LegacyServletResponse(resp));

  }

}

如果Jakarta EE以（逻辑）向后兼容当前规范和API为目标，这应该相当简单。如果遵循这一原则，这也将要求API的用户仅更新到Jakarta命名空间，以防他们想要使用已经需要代码更改的新功能。因此，我希望更改的命名空间不会过多地影响未来的Jakarta EE用户，但主要是那些实现其API的人的关注。回顾过去对Java平台的其他更基本的变化，例如，引入Java模块系统时也是如此，这主要涉及库和框架开发人员，但很少是Java的最终用户。

当然，对两个命名空间的支持永远不会是通用的，特别是从长远来看，因此Java EE API的用户最终需要对转换作出反应。鉴于规范保留了其API的二进制兼容性并排除了名称空间前缀的变化，我相信移植软件应该易于克服，甚至应该是可自动化的。任何Java类都在每个类文件的常量池中引用其导入的类型。使用新的jakarta前缀修补工件的所有常量池中的所有相关类型引用的工具将是微不足道的。这样做，Java EE的旧用户可以避免在被动维护下为其应用程序更改源代码，并且仅在编译后应用此类更改，甚至在部署期间修补工件。

什么驱动Oracle？

我当然是一名软件顾问，而不是国际商标管辖权的专家。我对甲骨文的决策过程也没有任何见解。因此，请将这最后一节作为有根据的推测与我的个人意见相混合而不是事实摘要。

Java社区中的一些声音目前正在指责Oracle通过限制javax命名空间的使用来反对Java及其用户的兴趣。 Eclipse基金会中也有激烈的争论，以至于有人建议以这种方式捐赠Java EE可能会被拒绝，因为它与组织的目标和价值观不相容。

鉴于这种变化确实给Java用户带来了重大的工作，当然可以很快得出这个观点。但是，我无法想象甲骨文会轻易做出这个决定。 Oracle已经并且一直在Java平台上进行大量投资 -  Java很少像现在这样活跃 - 但它也改变了它的战略方向。对我而言，Oracle在进行这些投资时“不关心”Java社区的想法根本不合适。

那么我认为如何推动这一决定呢？对我而言，限制与Java EE几乎没有关系，而是关于Oracle保护其对Java SE的兴趣。在一天结束时，甲骨文正在投资Java以获取利润。通过允许使用其商标，甲骨文将放弃对其品牌的控制权，从而使这一目标陷入危险境地。当然，Oracle依靠Java来生产自己的产品，并因此保留了它。但与此同时，该公司正在尝试创建一个战略模型，证明为数百名从事Java工作的全职和高素质员工提供资金。

甲骨文显然正在推动销售云解决方案，鉴于该公司目前在运营时和数据库方面的主导地位，除了雄厚的资金外，我相信他们在这一领域获得重要市场份额的机会要好于许多人的预期。 Oracle的另一个迹象是它对Graal VM及其编译器的投资，它还在资源受限的环境（如容器）中为Java语言提供了更广泛的应用范围。

但在投资某些领域的同时，甲骨文肯定也在研究削减成本的方法，例如终止不再具有战略利益或盈利能力不足的企业。虽然让用户（包括我自己）感到悲伤，但像Java飞行记录器这样的成功项目团队被解雇了，但考虑到绝大多数Java开发人员都没有要求这样的工具，这是有道理的。我认为Java EE不符合Oracle的平台计划或成本，并遭遇了类似的命运。.

有鉴于此，甲骨文可能考虑在放弃规范与捐赠给其他人维护之间进行权衡。虽然捐赠Java EE的选择似乎没有成本，但甲骨文当然会通过捐赠来承担风险。通过允许竞争组织继续他们在Java EE中的努力，这些努力也可能增强他们在Java SE领域与Oracle竞争的能力。对于红帽和IBM来说尤其如此 - 它们也在云解决方案市场上竞争。通过保护其品牌权，Oracle的目标只是降低Java EE被竞争对手武器化以在未来争夺Java SE市场份额的风险。公平地说，Oracle为Eclipse基金会提供了一种继续使用javax命名空间的方法。但是，这需要基础来限制自己将其产品与JVM的Java SE认证实现捆绑在一起，而不是例如它自己的IBM捐赠的OpenJ9。这样做，甲骨文将保留对其品牌的充分控制，但与此同时，签署如此广泛的协议不符合基金会的利益是非常可以理解的。它本来就没有意义，从这个角度来看，人们甚至认为Eclipse首先是接受Java EE捐赠的错误选择。

接下来是什么？

在开源社区，我们经常讨论我们的工作资金不足。虽然缺乏盈利能力对于个人开发者来说是个问题，但对于大型企业来说当然也是一个问题，无论是甲骨文还是参与当前讨论的任何其他公司。在我看来，通过Oracle捐赠Java EE的知识产权，Java社区已经交付了规范中最重要的部分，我们应该专注于我们拥有的东西，而不是被附加的字符串过度分散注意力。就个人而言，如果Oracle对Java品牌失去兴趣而不是采取立场，我会更担心Java的未来。

至于Jakarta EE，我不认为即将发生的命名空间迁移是规范面临的最大问题。许多开发人员甚至在最近的停滞期之前就对Java EE的尘埃感到沮丧。在我看来，问题是这个过程的一部分。实际上，Java EE规范通常源自领先框架的实现。如果另一个框架想要重新发明如何通过更好的API解决同样的问题，它需要面对不遵守标准的不断批评。这一切尽管这个标准通常只是以前最佳实践的快照。出于这个原因，我希望雅加达EE能够专注于它的发展，而不是过分坚持它的过去。通过提供最先进的API的引人注目的产品，我不会太担心调整我的代码，如果它让我免于实现最小化jakarta.servlet.Servlet API的迭代。

原文：https://dzone.com/articles/jakarta-ee-without-javax-the-world-wont-end-this-time-either

本文：http://pub.intelligentx.net/jakarta-ee-without-javax-world-wont-end-time-either

讨论：请加入知识星球或者小红圈【首席架构师圈】