Jakarta EE / MicroProfile的2021年前景


当然,由于多种原因,2020年将是历史上的里程碑。在Java社区内(除了Quarkus的普及之外),Eclipse基金会在Jakarta EE和MicroProfile的帮助下进行了大量工作。除了对明年的预测和期望之外,让我们仔细了解一下这一消息和去年取得的巨大成就。

谈到Eclipse Foundation的重要性总是很高兴的。除了IDE(它是Java世界中最常用的工具之一)之外,Eclipse Foundation还提供了一个协作创新的空间,并且该过程确保将所有这些知识产权都链接到开源。

Jakarta EE / MicroProfile回顾展

回顾今年这两个平台,我们可以从与雅加达有关的在线活动开始;雅加达一号有五种版本,使用几种语言,例如葡萄牙语,英语,日语和西班牙语。

当我们谈论发布时,在Jakarta EE世界中,我们有第九个版本,其影响最大,因为曾经是“ javax”的所有软件包都变成了“ jakarta”。在MicroProfile世界中,通过创建工作组和规范流程来启动4.0版本。MicroProfile的启动允许两个项目之间的互助。在MicroProfile 4.0版之前,只有MicroProfile可以使用Jakarta EE API,例如,与CDI,JAX-RS等一起使用。但是,Jakarta API将可以相互贡献也可以使用MicroProfile。

目前,正在讨论如何定义这种共同贡献。有几个初步的想法,这是加入电子邮件列表以提供您意见的机会。

后续步骤

为了避免在单个版本中产生重大影响,Jakarta EE 9仍发布了与Java 8兼容的版本。制作此版本后,下一步就是启动与Java 11兼容的新版本。

在MicroProfile方面,已经有关于与Jakarta EE 9兼容的版本以及该集成如何工作的讨论。

另一点是针对Java(CN4J)联盟的Cloud Native的发布,两个平台的集成基于此。尽管尚未获得“云原生”一词的书面定义,但我们知道开发和架构的未来将与云的计算模型联系在一起。

历史沿革

正如孔子所言:“如果您要预测未来,请研究过去”,因此重要的是要展示一些雅加达EE的历史和事件。

2016年,由于交付和参与平台的速度缓慢,Java EE收到了社区的几项投诉,这主要与甲骨文负责的规范有关。正是在这个时候,Reza Rahman领导了这个技术的兴趣小组的创建,当时该小组成立了Java EE监护人。今天,这个团体被称为雅加达大使。

同年,Devoxx UK和DevNation会议开始讨论一个新项目,该项目的重点是在此之前帮助Java EE。并且在2016年,Java正式宣布了Eclipse Microprofile。最初的成员​​与JCP执行委员会小组的成员相同:IBM,Red Hat,Payara,Tomitribe,LJC,Payara和SouJava。

该平台的前提之一是帮助Java EE中缺少的创新过程。因此,其最初的座右铭是:

快速创新的互动;

成熟度

通过JSR返回Java EE,使用JSR 382中的配置API尝试了该模式。

但是,当Oracle在将NetBeans代码库捐赠给Apache基金会几个月后,在2017年Oracle决定将代码和所有知识产权捐赠给Eclipse基金会时,这个故事变得更加有趣。

未来前景 一旦有了历史背景,我们需要讨论的第一点就是组织。过去,Java EE和MicroProfile具有分离感。但是,当前,这两个项目属于同一个组织Eclipse Foundation。Java原生云(CN4J)联盟打算以某种方式将它们结合在一起。

另一个重要的一点是,今年以来倾向于进入Jakarta EE系列的新规范。他们会:

Jakarta MVC:基于Jakarta EE(以前是JSR 371)的规范操作;

Jakarta NoSQL:Jakarta EE中诞生的第一个规范。它旨在促进Java世界与NoSQL之间的集成。

读取元数据的框架风格

在框架领域肯定引起广泛讨论的主题之一是关于Java类中的元数据读取,无论是选择还是每个类的影响。但是,这是什么意思?最终的开发人员往往对使用的API或注释没有太大的更改。但是,对于框架的体系结构,这往往需要进行许多更改。通常,这些框架在Java世界中都使用反射功能。这是一个大问题,因为类元数据的读取发生在运行时,而不是在ReflectionData中。使用Reflection会降低启动速度并增加内存消耗。

另一种选择是在编译时将生成元数据的整个过程带入整个过程。也就是说,在执行信息时,由于某些组件(例如Java注释处理器)在需要良好启动(如无服务器)的情况下,元数据将已经被处理并且不需要使用反射资源。另一个好处是可以在纯模式下使用代码。

基于各种框架的成功案例,Java通过GraalVM支持本机代码,例如Quarkus,Helidon,Micronaut和Spring。规范中也有一些举措可以探索这种类型的资源,例如CDI Lite。

当然,围绕每个时间的选择都有一些神话,因为每个选择都需要权衡取舍。这就是为什么史蒂夫·米利奇(Steve Millidge)撰写了一篇关于该主题的出色文章。

Modularization vs. Profiles

在Java EE的版本6中,第一个配置文件已启动:WebProfile。顾名思义,它是一个致力于减少磁盘消耗的配置文件。WebProfile将具有关于完整Java EE的八个规范,该规范包含所有规范,总共二十四个。

有人建议创建另一个配置文件LiteProfile,该配置文件比WebProfile轻。

另一方面,还有另一个选择:模块化。这种方法的最大优点是可以为特定应用程序精确选择依赖项。这种带有模块的模型是一种解决方案,已在Quarks,Spring,Helidon等Java框架以及Java世界中的其他平台中成功使用。另一个优点是,由于规格之间的组合数量很大,因此必须具有许多配置文件才能保留所有组合。使用模块,这将自然而然地发生。

The Year of Services

云的使用和采用是迫在眉睫且不可避免的。但是,为了加快此过程,有一种服务旨在降低复杂性并增加抽象度,从而降低使用云计算模型的风险。在《每位云工程师都应该知道的97件事》一书中,丹·摩尔(Dan Moore)解释了使用托管服务的重要性和简便性,因为除了基础架构之外,这种类型的服务还授予了管理和维护软件的知识。这样,诸如更新数据库,Java版本,执行备份,管理应用程序和数据库访问以确保安全性等重要活动将转移到此类服务上,从而使开发人员团队专注于交付业务。

与MicroProfile和Jakarta EE紧密相关的开发,有支持这两个平台的云管理服务。这些是一些示例:

Payara Cloud:是一种在云中管理应用服务器的简便方法。

Platform.sh:一种PaaS,旨在管理应用程序和应用程序所需的服务,例如数据库。PaaS方法将基础架构作为代码,团队将所有依赖项放入配置文件中。整个配置将完全使用GitOps概念负责PaaS 。

这些是可与MicroProfile和Jakarta EE一起使用的示例,并且也是云中的托管服务。即使此云工具没有直接链接到该过程,它无疑也有助于Java在云中的普及环境。据认为,今年这种流行趋势趋向于增长得多。


原文链接:http://codingdict.com