|
提起 Java EE 很多开发者都熟悉，但是它已经不再使用这个名称了，而是被开源组织改名为 Jakarta EE，那么改名后的它如今会是什么状况呢？我们一起来了解下。
在 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 规范（无遗留配置），以及少数其他子配置。 集成或包含服务网格。 上述选项的组合。
相关主题 |
