在 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，摘自：聊聊架构