jakarta ee_Jakarta EE 8朝着企业Java激动人心的未来冲刺

jakarta ee

第一个版本称为“ Jakarta EE 8”，将于9月10日发布。 为了庆祝这一点，开发人员可以参加一个虚拟的在线会议 -在线发布的视频将不少于19个一小时（以后将在Eclipse Foundation的YouTube频道上提供 ）。 演讲者中有许多国际知名的Java Enterprise专家。

Jakarta EE 8（您可能从名称中可以看出）在功能上与两年前发布的Java EE 8相同。 因此，您可能会认为在此期间发生的事情并不多，但是实际上，Java EE平台向Eclipse Foundation的迁移需要大量的精力； 必须将大量代码迁移到新的构建基础结构中。 这包括以前的参考实现“ Glassfish”以及TCK（技术兼容性套件），现在可以作为开源使用。 据称，这些文件总共有约550万行代码，以及超过61,000个文件中的超过220万行注释行。 这与《魔兽世界》和Linux内核2.6.0的后端相当。 因此，如果可以在Eclipse Foundation的基础架构上构建与Java EE 8兼容的应用服务器，并且可以在TCK的帮助下证明其兼容性，那么通过Eclipse Glassfish 5.1的发布就不能低估成功。

但这还不是全部。 此外，在幕后进行了艰苦的法律谈判，特别是对商标和使用权进行了谈判。 各个Java EE技术的规范文档已转移到Eclipse Foundation，并且通过了一个称为EFSP（Eclipse Foundation Specification Process）的新规范流程，它将在将来取代JCP。 EFSP规定，除其他事项外，不再存在所谓的规范线索，应使用“代码优先”的方法开发新功能，而不是从规范文档开始，并且应有“几种兼容的实现” ”，而不是单个参考实现。

在转移到Eclipse Foundation的过程中，还必须重命名各个Java EE技术。 因此，它不再称为“ Java Servlet”，而是“ Jakarta Servlet”等等。 虽然这种重命名在各处都被认为是令人讨厌的，但它也有一个积极的方面：花时间确保技术名称得到标准化并在一定程度上得到了简化。 到现在为止，名称还很不一致。 以前我们有“ XML绑定的Java体系结构”，“ JSON绑定的Java API”等不一致的地方，这种情况下的新名称现在是“ Jakarta XML Binding”和“ Jakarta JSON Binding”。 新名称的识别值总体上可以评为非常好。

Jakarta EE的下一步是什么？

现在，Jakarta EE的第一个版本已经发布，人们期待已久的平台的进一步开发终于可以开始了。 许多开发人员希望实现总体现代化和新功能，尤其是微服务的开发以及现代运营变体，例如云或Kubernetes。

在MicroProfile项目中，已经提出了许多有趣的建议，其中大多数已经显示出良好的稳定性。 毕竟，MicroProfile 3.0版已经可用，并且各种实现可供开发人员下载。 这些新功能包括对度量标准，健康检查和OpenTracing的支持，对OpenAPI的支持以及用于提高应用程序健壮性的扩展（超时，重试，回退，断路器，隔板）。 另一个有用的创新是Config API的实现，该API允许将来自不同来源的配置参数直接注入到应用程序代码中。 配置源可以是文件，环境变量，系统属性或专有源（例如数据库表）。 通过实施服务提供商接口（SPI），可以轻松实现对此类专有资源的支持。 注入配置参数后，MicroProfile实现会自动在所有可用的源中搜索合适的配置值。

还请参见：

因此，逐步将MicroProfile的创新移植到Jakarta EE上将是显而易见且可取的。 由于MicroProfile的开发已经非常先进，因此应该有可能从技术角度及时实现这一目标。 在MicroProfile路线图中已经可以找到更多有趣的创新。 在那里，您将找到对响应流，GraphQL，事件数据或对关系数据库的响应访问的支持。 但是，除了MicroProfile之外，一些现有技术还改进了一些新功能，例如JAX-RS，也可以很快将其合并到平台中。 在这种情况下，还应该提到Jakarta EE的发布周期要短得多。 与Java SE中发生的情况类似，将会有更频繁的发行版，只会带来较小的变化。 希望不久后将发布具有新功能的Jakarta EE版本。

除了新功能之外，还应简化一般的应用程序开发和平台介绍。 MicroProfile再次提供了一种可能的方法。 一个“ MicroProfile Starter”网站已经可以使用–与Spring Boot非常相似。 通常还可以观察到，许多MicroProfile的概念是从其他框架复制而来的。 但是，这不一定是负面的：为什么不采用在其他地方证明自己的想法？ 相反，识别值使在新的（旧）环境中更容易找到自己的出路。

毕竟，很明显与原始部署模型有所不同。 将单片应用程序服务器安装在功能强大的服务器上并部署了多个Java Enterprise应用程序的时代肯定已经成为过去。 它们不再适应当前趋势，例如云或Docker。 多年来，很明显，在许多地方，只有单个应用程序部署到应用程序服务器，这又引发了一个问题，即为什么该应用程序服务器实际上必须支持所有Java EE技术。 另一方面，仅支持此单个已部署应用程序实际需要的技术就足够了。 鉴于操作中的这种发展，应用服务器的制造商早就将其产品模块化到可以为每个应用构建或配置应用服务器的定制版本的程度。 此处的关键字是“ Just App App Server”。 例如，Build插件也可用于Maven，它将必要的应用程序服务器模块和应用程序打包到一个可执行的JAR文件中。 该模型与Docker和云更加兼容，并且其他框架也已对其进行了演示。

还请参见：

尽管进行了所有现代化和进一步发展，但将来仍将保留过去的主要优势之一：计划尽可能保持向后兼容性，以便较旧的应用程序也可以在当前的Jakarta EE实现上运行。 但是，与Java SE一样，计划在中期削减一些最古老的片段，并从平台中删除个别技术，或者至少将其标记为可选。 这应该主要涉及API，这些API一直很陌生，并且很少使用。

最后一件事…

因此，还有很多事情要做。 不幸的是，雅加达EE的发展还有最后一个障碍：平台的扩展不可避免地会导致现有API的扩展。 但是，Oracle只批准了在未更改状态下使用现有javax.enterprise.*软件包。 在更改或扩展的情况下，可能不再使用商标名称“ java”。 这有效地阻止了Jakarta EE的进一步开发，同时保持了当前的软件包结构。

查找新的软件包名称仍然非常容易（例如“ jakarta.* ”和“ jakarta.servlet ”）。 到底应该如何完成转换仍在讨论中。 如果将基础Java API移至新软件包，则所有现有应用程序将不可避免地变得不兼容。 那么该怎么办？

首先必须弄清楚所有Jakarta EE API的转换是一次硬切完成，还是要逐步引入新的软件包名称。 在每个版本中，只有实际更改的API才能迁移到新软件包。 到目前为止，还没有决定。 但是，如果坚决主张，那么下一个版本“ Jakarta EE 9”可能会包含对新软件包的更改，这是唯一的创新，而只有“ Jakarta EE 10”才能期待新功能。 幸运的是，如上所述，与Java EE相比，计划的发布周期要短得多。

一个相关的问题是如何最好地支持公司和开发人员迁移现有的Java EE应用程序。 一方面，可能会提供工具或IDE功能，以自动将现有应用程序项目的所有程序包依赖项重写为新程序包。 在代码级别上，这仍然相对容易实现，但是可能导致对外部库的依赖带来更大的困难。 已经提出的另一个建议是，Thorntail，Glassfish或OpenLiberty之类的容器在运行时在内部将旧软件包映射到新软件包，从而使它们对应用程序开发人员完全透明。

结论

随着Jakarta EE 8的发布，该平台已经达到了非常重要的里程碑。 软件包名称的问题仍有待解决，然后可以开始现代化和增加新功能。 对于拥有大量用于生产的基于Java EE的应用程序的公司来说，这是个好消息。 但是即使对于新应用程序的开发，Spring Boot也不是将来无可争议的佼佼者。 一系列令人振奋的新框架，例如Quarkus和Micronaut，正在MicroProfile的影响范围内前进。 这应该是一场激动人心的比赛。

翻译自: https://jaxenter.com/jakarta-ee-8-future-enterprise-java-161984.html

jakarta ee