改名之后的 Java EE，现在有什么新进展？

内容简介：在 Red Hat 最近的一次客户调查中，87％ 的受访者表示，他们正在使用或者考虑使用多种技术来开发微服务。同样的，在 2018 年 Eclipse 基金会 Jakarta EE 开发者调查中，68％ 的受访者表示，他们有超过 60％ 的应用...

在 Red Hat 最近的一次客户调查中，87％ 的受访者表示，他们正在使用或者考虑使用多种技术来开发微服务。同样的，在 2018 年 Eclipse 基金会 Jakarta EE 开发者调查中，68％ 的受访者表示，他们有超过 60％ 的应用程序在实现过程中使用了多种语言。

Jakarta EE 作为云原生 Java 的新家，从甲骨文手中接过 Java EE，计划在 2018 年第三季度发布符合 Java EE 8 规范的的 Glassfish 5.1，并基于新的认证流程在 2018 年第四季度发布符合 Jakarta EE 8 规范的 Glassfish 5.1，以此来确保交接的完整性。

其他可在 2018 年交付的包括 Java EE 8 规范、RI、TCK、现有规范和新规范的流程、兼容性过程等。目前，Eclipse 基金会正在组织 Jakarta EE 子项目。下一步，Jakarta EE 将开始启动在云计算、容器、微服务、无服务器计算和反应式技术方面的快速演化进程。Jakarta EE 在 2018 年计划：

• 得到充满活力的开发者社区的支持

• 增强对微服务架构的支持

• 转到云原生 Java

• 更快的创新：变得更加敏捷

• 提供具备生产级质量的参考实现

此外，Jakarta EE 将通过以下方式让生态系统变得更加现代化：

• 使用新的开放规范流程取代 JCP

• 新的治理结构

• 更开放的贡献方式

在 Jakarta EE 的发展过程中，它还必须想方设法保留受组织信任的 Java EE 功能。这在 Jakarta EE 中将会是什么样子？以下是社区目前正在讨论的一些注意事项：

• 可以将现有的完整配置标记为“稳定”或“建议可选项”，这样社区就可以专注于与云计算、容器、微服务、互联网 /Web 规模、高度分布相关的新功能。

• 摆脱配置的概念，并采用可组合 API 模型，也就是一种应用程序组装方法（类似于 WildFly Swarm，最近更名为 Thorntail），通过它创建的应用程序只需要 Jakarta API，而不需要其他东西。

• 需要在 Jakarta EE 中保留最小化的核心配置，可以基于这个核心配置构建其他配置。

• 需要定义多少个配置？可能需要核心（Servlet 或 CDI 或两者）、Web、微服务、完整和自定义。

• 提供一个遗留的完整配置（为了向后兼容）和一个新的完整配置，新配置包括云原生企业 Java 规范（无遗留配置），以及少数其他子配置。

• 集成或包含服务网格。

• 上述选项的组合。

英文原文：Jakarta EE: No turning back，摘自：聊聊架构

【声明】文章转载自：开源中国社区 [http://www.oschina.net]

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• NIPS改名被否，而在改名分歧之外我们能做的还有很多
• Windows 10 Spring Creators 更新改名为 April Update
• NIPS不改名引发学界大佬联名抗议，Jeff Dean领衔！
• Java EE 改名 Jakarta EE 后，又要换 Logo 了
• Java EE 改名 Jakarta EE 后，又要换 Logo 了
• USB-IF 再度为 USB 3 改名，这次更难辨别了

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。