jakarta ee_深入了解Jakarta EE 9发布计划

jakarta ee

新的一年已经开始，假期已经过去，对于大多数人来说，日常生活又重新开始了。 Jakarta EE社区也是如此-在过去几周的圣诞节休息之后，现在又开始着手实现2020年的宏伟目标，即发布Jakarta EE 9。

大爆炸

正如最近报道的那样，Oracle是第一个在去年年底开始为Jakarta EE 9制定自己的计划和想法并进行讨论的组织。 但是，由于Oracle在Jakarta EE的计划方面不再具有特殊的地位，因此这些想法​​主要用作讨论接下来的具体步骤的基础。

Jakarta EE平台项目负责Jakarta EE 9发布计划。 顾名思义，该项目负责平台规范，而平台规范又主要由众所周知的单个规范组成。 对于发布计划，平台项目仅收到了雅加达EE指导委员会的一些规范。

在2019年12月上旬，指导委员会决定Jakarta EE 9应该使用大爆炸方法从javax迁移到新的jakarta命名空间。 它还决定迁移包名称应成为Jakarta EE 9的中心目标，并且不会有新功能。 唯一的例外是一些规范，这些规范已从Java SE 9的JDK中删除，因此不可避免地需要它们。 稍后再详细介绍。

根据Oracle的初稿和社区在最近几周的反馈，Jakarta EE平台项目制定了发布计划并将其发布在网站上。 目前正在对该计划进行投票，尽管投票仍在进行中，但已经很明显，当前版本的投票多数。 因此可以假设该计划将在本周内获得批准。 有足够的理由来仔细研究。

Jakarta EE 9发布计划

正如Jakarta EE指导委员会已经指定的那样，计划文档首先描述了名称空间迁移是Jakarta EE 9的主要目标。因此，Jakarta EE 9中包含的所有规范都必须从javax包迁移到新的jakarta包。 除此之外，不应该对规范进行任何更改，这意味着很可能不会有任何新功能。 但是，该文件还提到可以例外，但需要明确同意。 但是，任何规范都不太可能希望利用这种可能性。

由于软件包名称的更改是与以前版本的兼容性方面的非常严重的更改，因此所有规范都必须获得新的主要版本。 因此，Jakarta EE 9将包含Jakarta Servlet 5.0，Jakarta Persistence 3.0和Jakarta Server Faces 3.0，仅举几个例子。 可以肯定地说到强制跳到下一个主要版本的感觉，尤其是因为它只是部分“重大变化”。 尽管软件包名称发生了变化，这本身就是兼容性的破坏，但规范没有任何其他变化，因此在许多情况下，可以通过简单的“搜索并替换”来完成自身源代码的迁移。

文献资料

此外，建议针对新名称空间修改规范文档。 不幸的是，这不可能对所有文档都可行，因为并非所有项目都可以访问这些文档。 这是由于以下事实：目前尚未满足所有法律要求，以允许在Eclipse Foundation的保护下进一步开发规范文档。

这样做的原因是，过去为文档做出过贡献的所有作者都必须明确许可所有内容以有序方式合法运行。 由于某些文档已有10多年的历史了，因此遗憾的是这项任务不太容易实现。 这意味着仍然存在某些文档可能根本无法发布的危险，因此必须重写。 我们一直在努力，Eclipse基金会很快在这方面有了好消息。

在Oracle的Jakarta EE 9计划的初稿中，预计该平台将不需要向下兼容旧的javax名称空间。 这应该使新的应用程序服务器制造商更容易上手。 现有的应用程序服务器很可能会提供它们自己的某种向后兼容性，从而允许旧Java EE应用程序的运行来适应他们自己的客户。

Java SE

前面提到的另一点涉及Java SE版本的要求。 Java EE 8和Jakarta EE 8都需要Java SE8。尽管Java SE 8在今天仍然很普遍，但一段时间以来，Java SE的新LTS版本Java SE 11才可用。 因此，Oracle在该计划的初稿中建议将最低要求提高到Java SE 11。

但是，在发行计划中，实现方式有所不同–现在的要求是，所有规范都必须使用源级别8进行编译，但是应用服务器必须在Java SE 11的基础上证明其兼容性。足以满足许多开发人员的愿望：即使Jakarta EE API本身仅使用Java SE 8，也可以使用Java SE 11开发Jakarta EE 9应用程序。

还请参见：

技术指标

唯一剩下的问题是，哪些规范首先将成为Jakarta EE 9的一部分。 Oracle在计划的初稿中提出了利用此机会删除该平台的一些过时部分的建议。 这背后的想法当然是使命名空间迁移的工作尽可能小。 毕竟，为什么要花时间和精力在不再相关的规范上并已经被标记为“已弃用”？

在过去的几周中，已经对不赞成使用的候选人名单进行了深入讨论。 但是最后，该列表比Oracle最初提出的要小。 这主要是由于一些供应商对删除仍然由其自己的客户积极使用的规范的想法不太满意。 尽管Oracle最初明确表示即使平台不再需要产品，产品当然也可以继续支持相关技术，但实际上情况并非如此。 现在很明显，以下规范将不属于Jakarta EE 9：

• 雅加达XML注册中心
• 雅加达XML RPC
• 雅加达部署
• 雅加达管理
• EJB 3.2核心规范中对分布式互操作性的支持

考虑到最初甚至讨论了将SOAP Web服务的支持作为删除的候选对象，所以这个相对较小的列表可能很容易处理。 另外，另外两个规范被分类为“可选”：

• Jakarta Enterprise Beans 2.x API组
• 雅加达企业Web服务，JSR 109

但是，如上所述，一些新规范也将包含在Jakarta EE 9中。这些都是Java SE以前的全部技术，但不再包含在较新的版本中。 由于Jakarta EE 9现在还针对缺少这些API的Java SE 11，因此必须在此处找到解决方案。 具体来说，涉及以下规范：

• 雅加达激活
• Jakarta XML绑定
• 雅加达XML Web服务
• Jakarta Web服务元数据
• 带有附件的Jakarta SOAP

除了前两个之外，一个人很想知道为什么它们首先成为Java SE的一部分。 尤其是主题“ Web服务”，它实际上属于企业类别，并且从一开始就应该成为Java EE的一部分。 最初讨论的是五个规范中的某些规范是否甚至不应该保留在javax命名空间中，但最后还是同意忠实于“大爆炸”策略，并将其全部移入jakarta命名空间。

时间表

最后，我们提出了最令人兴奋的问题之一。 时间表到底是什么样的？ 发布计划中还将详细讨论此方面。 首先，已决定将规范分八个阶段发布。 这主要是由于它们之间的依赖性。 例如，Jakarta Server Faces依赖于Jakarta表达语言，这当然意味着它必须提前发布。 因此，第一阶段更可能包含核心规范，例如Jakarta Servlet，Jakarta Interceptors和Jakarta Expression Language，而平台规范本身处于最后阶段。 该文件明确指出，需要里程碑和候选版本，以便更高阶段的规范可以尽快更新其依赖性。

还请参见：

关于具体的时间表，该文档如下：在2月中旬，即一个月的时间内，所有规范都应提供已经转换为jakarta名称空间的API的第一个版本。 到3月中旬，应该对Jakarta EE TCK进行必要的修改。 从那时起，由于新的程序包名称，实施项目将能够进行必要的调整。

然后计划在5月初发布该平台规范的第一个发行候选版。 6月中旬，将对该版本进行最后一轮投票； Jakarta EE规范流程要求这样做。 因此，最终版本有望在7月发布。 该计划比Oracle最初计划的野心更大，后者最初的目标是2020年9月发布。

总结思想

总体而言，发布计划给人留下了深刻的印象。 尽管之前曾对一些问题进行过极具争议性的讨论，但已经为Jakarta EE 9的框架达成了一致，每个人或多或少都对此感到满意。 当然，Jakarta EE 9并没有带来任何技术创新，而是完全专注于新软件包名称这一主题，这令人有些失望。 尽管如此，Jakarta EE 9当然是一个非常重要的版本，使Jakarta EE社区摆脱了传统和法律的限制。

翻译自: https://jaxenter.com/jakarta-ee-9-release-plan-deep-dive-166910.html

jakarta ee