如果您错过了新闻， 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。

翻译自: https://www.javacodegeeks.com/2019/05/jakarta-ee-without-javax-world-wont-end-time-either.html