雅加达EE 8：过去，现在和未来


在本文中，我们将解释Jakarta EE 8的全部含义。 但是在我们去那里之前，让我们先回顾一下历史。

过去

Java于1996年与当时称为Internet的Netscape收购的Kiva Enterprise Server一起发布。 同时，BEA收购WebLogic之后不久，一家名为WebLogic的公司就一直在使用完全不同的API来致力于类似概念的“应用服务器”。

与Sun Microsystems一起，主要基于这两个服务器设计用于广泛通用框架的初始API（JDBC，EJB，Servlet和JSP）。 1999年末，该框架的第一个版本问世：名称有点混乱的J2EE 1.2，由前面提到的Kiva（现在称为iPlanet Application Server（iAS）和WebLogic）实现。

J2EE是（某种程度上）开放的标准，这意味着它可以由其他方许可，然后其他方可以提供它的认证实现。 后来，这些团体甚至可以通过称为JCP的程序加入规范的设计。 Java Community Process，在其整个时期变得越来越开放。

J2EE 1.2对市场产生了很大的影响，很久以前，许多公司都推出了与其兼容的产品，包括IBM WebSphere 4，BEA WebLogic 6.1，Oracle 9i AS，Tmax Soft JEUS 3.0，Borland AS 4.5，NEC WebOTX 4.2等。 J2EE在2001年发展到1.3，在2003年发展到1.4，并有19种实现，其中OSS实现是JBoss AS，JOn AS和Apache Geronimo。 值得一提的是，也存在一定数量的J2EE部分实现，例如Tomcat，Jetty，Resin和IronFlare的Orion。

在此期间，我们还看到了一些更大的收购案。 红帽收购了JBoss，Oracle收购了IronFlare和BEA。

尽管实现了许多实现，但J2EE 1.4还是遇到了障碍。 一个以复杂墙的形式。 在2006年中期，以Java EE 5的形式或多或少地重新启动了J2EE，Java EE 5着重于开发人员友好性和配置约定。 但是，实现兼容的公司数量减少了，原始实现的数量甚至更少了，基本上包括GlassFish，WebSphere，WebLogic，JBoss AS，JOn AS，Geronimo，JEUS和NetWeaver。 Java EE 5在2009年末演变为Java EE 6，它引入了许多“现代” API，特别是JAX-RS和CDI，以及人们期待已久的重新启动JSF（恰当地命名为JSF 2）。

但是，大约在同一时间，Sun被Oracle收购，这极大地改变了Java EE生态系统的动态。 由于Oracle已经收购了BEA（WebLogic）和IronFlare（Orion），因此它现在还拥有GlassFish，此外，JCP的功率方程式还消除了多余的力量。 随着Apache离开JCP以及Geronimo和JOn AS悄然消失，Java EE市场从本质上减少到了Oracle，IBM和Red Hat这三个主要参与者，再加上体积小得多的Tomitribe，它们留下了一些剩余的东西。在Geronimo的支持下获得了一个名为TomEE的新AS。

还请参见：

与5和6相比，2013年发布的Java EE 7相对而言版本5和6相对较小，最终揭示了现代Java EE平台的含义。 具有可组合拦截器，验证服务和扩展点的核心bean模型。 本来应该用Java EE 8来完成该模型的开发，但随后事情就大大放缓了。 Java EE 8的发布范围大大缩小了，Oracle在2017年底宣布将把Java EE转移到Eclipse Foundation。

现在

转移已经进行了大约两年，其中包括许多步骤：

  • 审查和清理现有的源代码
  • 实际转移的代码，包括问题
  • 设置作业以在Eclipse基础架构上构建一切
  • 将所有组件的Maven坐标更改为雅加达。*
  • 发行Eclipse GlassFish 5.1 ，该版本完全由Eclipse的已移植源构建而成，并通过了现有的Java EE 8 TCK（并正式进行了认证 ）
  • 设计新的Jakarta和Eclipse规范和认证流程以替代JCP，并获得新的规范许可证
  • 传输Java EE TCK源
  • 根据新规范许可，从转让的TCK来源构建一系列TCK二进制文件
  • 将构成Java EE 8 API的所有项目转换为规范项目，并替换Oracle商标用语或Oracle和Eclipse之间协商解决的其他不再使用新用语的术语
  • 向规范项目添加新的范围声明
  • 针对更新的API 运行新建的和获得许可的TCK ，针对分阶段的构建运行Jakarta EE 8的认证请求
  • 释放暂存的API罐

完成所有工作后，我们将发布一个Jakarta EE 8 API版本，该版本与它源自的Java EE 8 API具有相同的签名，但通过Eclipse Foundation进行了完全构建，许可，测试和认证。及其过程。

在撰写本文时，上述列表中的倒数第二个步骤正在紧锣密鼓地进行，我们预计很快就会完成工作，应该在2019年8月下旬之前进行。之后，WildFly，Open Liberty和其他公司将很快获得Jakarta EE 8认证。

如上所述，Jakarta EE 8将为所有众所周知的API带来一组新的名称。 对于这些新名称，我们（决定委员会和提交者）集体决定优先使用小名称，而不是较长的名称，尤其是避免使用晦涩的缩写。 Java EE的长期用户当然习惯于使用JMS，JTA，JCA，JPA，JSF，EJB等缩写，但是对于新手来说，这经常被认为是入门的障碍。 在研究名称时，我们发现它们实际上是非常不一致的。 即，为什么JMS是“服务”，JTA是“ API”，JCA是“架构”？ 几乎总是这些词实际上只是某种填充词，并没有真正带来任何附加值。

还请参见：

为了便于讨论，我们将新名称分为三层：

方法1：一个字

  1. 雅加达Servlet
  2. 雅加达面Kong*
  3. 雅加达WebSocket
  4. 雅加达并发
  5. 雅加达拦截机
  6. 雅加达认证
  7. 雅加达授权
  8. 雅加达安全
  9. 雅加达消息
  10. 雅加达坚持
  11. 雅加达楼盘
  12. 雅加达批次
  13. 雅加达邮件
  14. 雅加达连接器
  15. 雅加达注释
  16. 雅加达激活
  17. 雅加达NoSQL

方法2：两个字

  1. 雅加达Bean验证
  2. 雅加达表达语言
  3. 雅加达企业豆
  4. Jakarta XML绑定
  5. Jakarta JSON绑定
  6. 雅加达JSON处理
  7. 雅加达服务器页面

方法3：三个字或以上

  1. 雅加达XML Web服务
  2. 雅加达RESTful Web服务
  3. 雅加达标准标签库
  4. 雅加达语境和依赖注入

（*由于时间安排的问题，暂时将其称为Java Server Faces，但目的是尽快解决此问题）

未来

一个棘手的问题仍然悬而未决，这将所有Java API包从javax。*重命名为jakarta。*。 例如javax.servlet.http.HttpServletRequest将成为jakarta.servlet.http.HttpServletRequest 。

显然，这是一个会影响现有代码的更改，因此应该制定一个好的策略。 有很多不同的选择，包括借此机会也将重命名为奇特的程序包（例如javax.security.auth.message）重命名为jakarta.security.auth.message。*，而是直接重命名为jakarta.authentication，以匹配（新）规格名称。 正在考虑的其他选项是所谓的“大爆炸”重命名（一次性重命名所有内容）或递增重命名（仅在需要更新该API中的任何内容时重命名整个API）。 仍然需要做出决定，但是从各种民意调查，观点和讨论中，似乎以下是选项的首选组合：

  • 大爆炸（ 一口气重命名所有API ）
  • 仅限javax。*至jakarta。*（ 不涉及程序包名称的任何其他部分 ）
  • Jakarta EE 9仅涉及重命名（ 没有其他新功能，这将是EE 10的主题 ）

另一个未解决的问题是规范文档的传输。 尽管所有工作都在进行中，但这仍然没有发生，但预计会在合理的时间内发生。 同时，Jakarta EE 8因此发布时没有“真实的”规格文档，而是带有所谓的样板规格文档。 该文档实质上仅包含许可证和范围，而没有其他内容。 当然，API的Javadoc也已成为规范的一部分。

我们都期待着最终拥有转让流程，并开始开发下一代Jakarta EE。 如果遵循上述重命名路径，则将其命名为Jakarta EE 10，或者有时将其称为Jakarta EEX。

JakartaOne LiveStream上将披露此难以捉摸的X版本中可能显示的一些计划，因此，如果您对Jakarta EE的未来感兴趣，请务必参加！

该博客文章最初出现在Eclipse Foundation的August时事通讯中 。

翻译自: https://jaxenter.com/jakarta-ee-8-past-present-future-161990.html