没有Javax的Jakarta EE：这次世界也不会结束

如果您错过了新闻， Oracle将向Eclipse基金会捐赠Java EE规范。这项决策在规范过程中经历了相当长时间的休眠，在此过程中，人们理所当然地怀疑Oracle对Java EE失去了战略兴趣。起初，Java EE和更广泛的Java社区很好地满足了捐赠规范的决定。在没有Oracle减慢流程速度的情况下，Java EE涉及人员可以再次尝试关闭非标准化的API。直到今天，由于Oracle和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的指定E X内java的X命名空间抚育的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的正式用户。

尽管有这种形式上的区别，即使您只编写了普通Java而没有包括任何外部依赖关系，您也可能会遇到Java EE及其javax名称空间。这是因为选定的Java EE API与JVM的标准映像捆绑在一起。除了API之外，JVM还附带了该API的默认实现，以使用户能够轻松解决常见任务。例如，JAXP是Java EE规范，它定义了用于在Java中处理XML的API。 XML处理是一项常见的任务，尤其是在面向企业的Java平台上，将XML包含在内是一个合理的选择。对于JAXP，其假定的通用用法在今天仍然是事实，但是其他与JVM捆绑在一起的Java EE规范的老化程度也不尽相同。例如，对于大多数Java开发人员而言，SOAP消息传递不再是首选，因此JVM捆绑的JAX-WS实现已成为大多数用户的负担。为了减少JVM的占用空间并在Java 9中引入Java模块系统，一些Java EE API已移至已弃用的模块，这些模块计划在将来的版本中删除。当然，这并不意味着模块的API本身已被弃用。 JAX-WS仍然活跃并且被许多人积极使用。但是，由于不赞成使用此模块，希望在将来的Java版本中继续使用JAX-WS的人员必须将其作为显式依赖项添加。

在我们在虚拟化硬件上运行微服务的时代，减少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哲学中，Java SE用于面向用户的桌面应用程序，而Java EE用于多个并发用户使用的服务器应用程序。本着这种精神，例如，JDBC连接接口是在java.sql包中定义的。毕竟，桌面用户当然可能要连接到数据库。另一方面，由于仅将连接池视为多线程服务器应用程序的要求，因此在javax.sql包中定义了JDBC DataSource接口。从今天的角度来看，这种分离当然不再有意义，但是名称空间和形式上的区别直到今天仍然存在。

当然，在由OpenJDK项目管理的Java SE和现在由Eclipse基金会管理的Jakarta EE内，分别使JDBC API演变是没有意义的。因此，并不是将Java EE规范的所有部分都捐赠给了Eclipse，因此将为JDBC API保留javax.sql命名空间，该JDBC API现在被认为仅是Java SE的一部分。保留此类API的其他示例是JMX API，它严重依赖于本机JVM支持。当然，所有一直被认为是Java SE一部分的其他API（例如也以Java扩展名称空间结尾的Swing API）将保留在其原始包中。

向后兼容性呢？

要记住的重要一点是，无论是现在还是将来，目前都不会消失现有的javax API。我个人也希望Jakarta EE现在包含的规范能够在未来很多年内支持javax命名空间。实际上，对于大多数Java EE实现而言，处理多个名称空间并不是什么新鲜事物，但始终是一个重要的主题。例如，当用JPA规范定义的注释逐步替换其注释时，Hibernate库已经成功完成了类似的迁移。在另一个示例中，Spring框架与其本机注释并行地支持Java EE CDI规范。这样做，例如，可以通过使用
javax.inject.Inject注释或Spring的本机Autowired注释。一旦将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的最终用户。

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

是什么推动了Oracle？

我当然是软件顾问，而不是国际商标管辖权的专家。我对Oracle的决策过程也没有任何见解。因此，请把这最后一部分当作有根据的推测，加上我的个人观点，而不是事实摘要。

Java社区中的一些声音当前正在指责Oracle通过限制Javax名称空间的使用来违反Java及其用户的利益。在Eclipse基金会中也进行了激烈的辩论，以至于有人建议以这种方式捐赠Java EE，因为它与组织的目标和价值不兼容。

鉴于这一更改确实对Java用户带来了巨大的工作量，因此当然可以很快得出这一观点。但是，我无法想象Oracle会轻率地做出这个决定。甲骨文正在并且一直在Java平台上进行大量投资-Java至今还没有像现在这样活跃-但是它也改变了其战略定位。对我而言，甲骨文在进行这些投资时并不“关心” Java社区的想法根本不合适。

那么，我认为该决定的动机是什么？对我来说，限制与Java EE无关，而是关于Oracle保护其对Java SE的兴趣。归根结底，甲骨文正在向Java投资以获利。通过允许使用其商标，甲骨文将放弃对其品牌的控制权，从而使这一目标陷入危险。当然，Oracle依靠Java来开发自己的产品并因此维护它。但是与此同时，该公司试图创建一种战略模型，以证明为数百名从事Java工作的全职高素质员工提供资金。

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

但是，尽管在某些领域进行投资，Oracle肯定也在寻找削减成本的方法，并终止不再具有战略意义或盈利能力不足的企业。尽管让用户（包括我自己）感到沮丧的是，像Java飞行记录器这样的成功的项目团队被解雇了，但考虑到绝大多数Java开发人员都不需要这种工具，这是有道理的。我相信Java EE既不适合Oracle的计划，也不适合该平台的成本概况，并且怀有类似的信念。

有鉴于此，Oracle可能考虑了放弃该规范与将其捐赠给其他人维护之间的权衡。尽管捐赠Java EE的选择似乎是没有成本的，但是Oracle无疑会为此做出冒险。通过允许竞争的组织继续他们在Java EE中的努力，这些努力还可以增强他们在Java SE领域与Oracle竞争的能力。在Red Head和IBM参与了云解决方案市场竞争的那些组织中，尤其如此。通过保护其商标权，Oracle的目标仅仅是降低竞争对手使用Java EE争夺Java SE市场份额的风险。公平地说，Oracle为Eclipse基础提供了一种继续使用javax名称空间的方法。但是，这将需要基金会将自身限制为将其产品与Java SE认证的JVM实现捆绑在一起，而不是例如将其自己的IBM捐赠的OpenJ9捆绑在一起。这样做，尽管Eclipse使用了javax名称空间，Oracle仍将保留对其品牌的足够控制权，但是同时，签署如此广泛的协议也不符合该基金会的利益是可以理解的。只是不意味着如此，因此，甚至有人可能会认为Eclipse首先是接受Java EE捐赠的错误选择。

接下来是什么？

在开源社区中，我们经常大声讨论我们的工作资金不足。而且，尽管缺乏盈利能力对于单个开发人员来说难以解决，但对于大型公司（无论是Oracle还是当前讨论中涉及的任何其他公司）而言，这当然也是一个问题。在我看来，通过Oracle捐赠Java EE的知识产权，Java社区已经移交给了该规范的最重要的价值，我们应该集中精力处理已有的东西，而不要因附加的字符串而过度分散注意力。就个人而言，如果甲骨文失去了对Java品牌的兴趣而不是站稳了脚跟，我将更加担心Java的未来。

对于Jakarta EE，我都不认为即将到来的名称空间迁移是规范面临的最大问题。甚至在最近的停滞期之前，许多开发人员就对Java EE的灰尘感到沮丧。我认为，问题是该过程的一部分。实际上，Java EE规范通常来自领先框架的实现。如果另一个框架想要重新发明如何通过更好的API解决相同的问题，则需要不断批评该框架不遵守该标准。尽管事实是该标准通常只是先前最佳实践的快照，但所有这些。因此，我希望Jakarta EE可以专注于其发展，而不是过多地保留其过去。有了引人注目的最先进的API，如果它使我免于实现最小改动的迭代，那么我就不必担心调整代码。
jakarta.servlet.Servlet API。