雅加达poi_雅加达EE 9 –标志着巨大的爆炸

雅加达poi

考虑到Java企业版的最后两到三年，Oracle对Java EE的热爱很可能会受到质疑。 但是，任何认为Oracle对Java版本没有任何责任感的人都会再次被证明是错误的。 除了Oracle架构师Bill Shannon，其他人都没有提出关于Jakarta EE的第一个“实际”发行版（Jakarta EE 9）的建议。

Jakarta EE 9将是Eclipse Foundation旗下的第一个“功能版本”，但实际上是第二个版本。 Jakarta EE的版本8与Java EE 8的版本相同，可以看作是从Oracle迁移到Eclipse Foundation的最终里程碑。

Jakarta EE 9 – Oracle的建议

Bill Shannon提出的有关Jakarta EE 9的计划不应视为Oracle的正式计划。 专门的社区成员是Oracle Java EE社区的成员，并且当然还与他的同事讨论了Enterprise Java项目的下一步可能是比较巧合。 这些考虑和想法导致了Oracle的声明 ，经过一些评论后最终对其进行了修订，并以当前的形式接受了Oracle的正式建议，并被社区作为讨论的基础。

清理

Jakarta EE 9计划的第一部分涉及从Jakarta EE 9中删除一些规范：

• 雅加达XML注册中心
• 雅加达XML RPC
• 雅加达部署
• 雅加达管理
• Jakarta Enterprise Bean实体Bean
• Jakarta Enterprise Bean互操作性
• Jakarta Enterprise Bean 2.x和1.x客户端视图
• 雅加达企业Web服务

这些将在Eclipse Foundation上仍然可用，但是不会更新。 当然，实施项目仍然应该可以运行服务更新； 毕竟规范仍然有一些用户，但是它们不应由官方平台规范定义。 同时， Payara的史蒂夫·米利奇（Steve Millidge）建议将“ 雅加达管理”作为一种选择提供，并在以后进行扩展。

此外，也有一些是密切相关的Java SE 8， 不应该实施的API：

• 雅加达XML Web服务
• 雅加达SOAP附件
• Jakarta Web服务元数据
• CORBA和RMI-IIOP

除此之外，Bill Shannon建议在即将发布的企业版中实现Jakarta XML Binding和Jakarta Activation 。

大爆炸

由于Oracle明确指出，Jakarta EE的名称空间javax.*仅在规范的状态下可用，因此很明显，必须重命名软件包。 但是，至今尚不清楚是只将真正更改为新名称空间的规范移动，采用渐进方法，还是最好立即同时移动所有规范。

后者以所谓的“大爆炸”方法进入讨论，似乎征服了大多数开发人员和社区成员的心。 Bill Shannon的建议是将所有规范（在清理后仍保留）直接移动到jakarta.*名称空间。 优点：在一次向下兼容一次努力之后，Jakarta EE的进一步开发可以开始，而不必在每个发行版中都重新检查命名空间问题。

现有项目的向后兼容性问题不应成为Jakarta EE规范的一部分。 相反，基于Java EE或Jakarta EE的产品应自己负责。 为此也可能会建立一个单独的开源项目。

Java SE，TCK，微服务和容器

从逻辑上讲，Jakarta EE 9也应该支持Java SE。 最低版本是最新的长期发行版本Java11。此外，应考虑Java模块，并应为定义模块的规范制定规则和准则。 Jakarta-EE-9平台本身不应该模块化，但是应该更好地支持微服务-这也适用于不使用容器的情况。

TCK项目的划分是一个需要大量工作的愿望。 这个想法的目的是使Jakarta EE平台的所有项目都能管理自己的TCK。 但是，Jakarta EE 9并未考虑这一点。一方面，由于上述工作量，另一方面，由于必须确保此类更改不会使测试Jakarta EE产品更加困难。

MicroProfile + Jakarta EE =明天的企业Java？

自从我们发布《 理解雅加达EE》系列以来已经有一段时间了。 那时，大多数人对是否应将MicroProfile转移到Jakarta EE项目的问题回答“否”。 根据大多数参与者的意见，MicroProfile应该保持一个独立的项目，在其中可以测试创新的想法和概念。 可以说，一个小型孵化器为Jakarta EE带来了更大的好处。

Bill Shannon的建议现在引起了另外一个注意：MicroProfile API将在Jakarta EE平台中实现，该项目的工作将置于Jakarta EE规范流程的保护下。 但是，对于Jakarta EE 9而言，这将不会实现。如果遵循的话，这将不是一条容易的路径，因此将有更多时间使用它。

Jakarta EE 9及更高版本的展望

从Bill Shannon的提案以及Red Hat和Payara的回复中可以看出，现有的API和规范将不会被修改。 造成这种情况的原因是名称空间问题：如果您已经在移动，那么您就不应该对要移动的资产进行返工–稍后会有时间。

因此，迹象表明“大爆炸”，并且发布日期也已经宣布。 目标是在Jakarta EE 8之后最多12个月内完成Jakarta EE9。这意味着可以在2020年秋季发布Jakarta EE版本，这可以作为进一步开发平台和个别规范的基础–起初听起来很积极。

另一方面，12个月也是很长的时间，我们将在接下来的几周内看到景观如何发展。 使Jakarta EE成为云原生Java的权威的工作肯定不会结束。

Bill Shannon当前的建议以及有关该建议的整个讨论都可以在邮件列表jakartaee-platform-dev中找到 ，有兴趣的人可以免费使用。 如果您想参加，只需在此注册即可。

翻译自: https://jaxenter.com/jakarta-ee-9-big-bang-163143.html

雅加达poi