Jakarta EE和Eclipse MicroProfile –两个名字,一个家族?

金慈
2023-12-01

最近,Sebastian Daschner写了一篇博客文章,其中包含有关Jakarta EE的创新及其与MicroProfile关系的建议。 我们与他取得了联系,并向他询问了有关该提案,当前情况以及接下来会发生什么的几个问题。 继续阅读,找出他必须说的话。

Jakarta EE和Eclipse MicroProfile

JAXenter:MicroProfile和Jakarta EE都旨在简化针对云/微服务上下文的Java EE应用程序的开发。 从历史上看,Jakarta EE是Java EE的继承者,MicroProfile是Oracle几乎没有对Java EE的未来发表任何看法时创建的一个新项目。 但是Java EE的未来现在很清楚–在Eclipse Foundation的主持下的Jakarta EE。 为什么我们根本需要一个Eclipse MicroProfile项目?

Sebastian Daschner:目前,Jakarta EE尚未退出市场,MicroProfile包含非常有价值的项目。 MicroProfile中的一些东西直接来自EE,例如CDI或JAX-RS,但是MicroProfile Config,Fault Tolerance,Metrics,OpenAPI等通过其他必需技术来补充Enterprise Java。 许多项目将Java EE与MicroProfile结合使用,多个运行时(例如Open Liberty或Payara)都支持Java EE和MicroProfile,到目前为止,这是一种实用的解决方案。

JAXenter:现在来看:Eclipse MicroProfile和Jakarta EE之间的技术区别是什么?

Sebastian Daschner:从技术上讲 ,差异很小:软件包名称不同,并且MicroProfile包含的内容少于Java EE / Jakarta EE。 另一方面,MicroProfile项目通常具有我们从Enterprise Java中了解到的相同“外观”,相同的开发人员体验和声明性方法。 目前,MicroProfile项目可以比Java EE标准更快地创新和发展。 另外,Jakarta EE即将发货,因此,到目前为止,EE的规格尚无进展。

创新,协作

Sebastian Daschner:我想开始讨论雅加达的创新过程是什么样子。 尽管Jakarta EE尚未解决,但我认为现在是开始思考一些关键问题的好时机。 例如,雅加达将如何创新,在MicroProfile中完成的工作会发生什么,以及从用户的角度来看,理想的画面将来会是什么样子。 但是动机主要是开始对该重要主题进行讨论。

在JCrete,我们与来自IBM和Red Hat的其他Enterprise Java社区成员进行了非正式讨论,我们正在讨论最终导致该建议的要点。

JAXenter:您能否再次简要概述要点? 你有什么建议?

塞巴斯蒂安·达斯纳(Sebastian Daschner):要点之一是,我们需要就孵化器项目的外观以及如何形成一个共识,并最终制定一个明确的流程。 这样做的原因仅仅是因为EE的主要优势始终是开发人员体验的一致性,API的使用方式,统一的设计原则(例如,约定优于配置,声明性方法等)。一年前,我写了一些我认为这些原则使EE成为一项很棒的技术,请参阅博客文章: https://blog.sebastian- daschner.com/entries/雅加达 ee-design-principles 。 为了保持这一优势,我认为需要有一个更统一的想法。

…我认为Jakarta和MicroProfile是一个家族,我们需要确保所有规范都可以从所进行的更新中受益。

要解决的另一点是,我们如何处理已经在Java EE和MicroProfile中看到一些分支的情况,这仅仅是因为我们还不能提升Java EE规范(例如JAX-RS或CDI)这一事实,例如导致了MicroProfile REST客户端。 从简单的技术角度来看,更新JAX-RS当然更有意义,但这是在这种情况下唯一可以做的事情。 同样,我们拥有基于MicroProfile Config的Config JSR,该JSR计划在JCP下创建,现在已在Jakarta下重新启动。 现在,在将来对Enterprise Java进行更多的思考,再从技术的角度来看,我认为Jakarta和MicroProfile是一个家族,我们需要确保所有规范都可以从所做的更新中受益。 这意味着,雅加达的所有事物迟早都需要使用正在开发的创新技术,例如在配置方面。 讨论的问题是,如何从用户的角度,最好是从用户的角度,以统一的开发人员经验,共享的设计原则,相同的程序包名称等将这张图片放在一起。

还请参见: “ Jakarta EE应该解决Java EE过去的一些缺点”

贾克森特(JAXenter):在邮件列表上,有人表示担心该提案可能会分裂社区。 用户必须始终决定是否支持MicroProfile或Jakarta EE –或两者都支持。 您还看到分裂的危险吗?

塞巴斯蒂安·达施纳(Sebastian Daschner):是和否。 在规范级别上,我们确实已经有一些划分的迹象,例如查看REST客户端,Config JSR,并发/上下文传播,这些都有很好的理由。 从用户的角度来看,我认为并没有什么大的危险,因为许多项目已经使用Java EE和MicroProfile的组合,仅仅是因为大多数项目都需要这两种技术。 这就是为什么我们有多个运行时支持两者的原因。 但是,从整个Enterprise Java的角度来看,再次看到两个品牌作为一个家族包含的整套技术才有意义,并且我们应该考虑将来如何将这些技术结合在一起,最好是在一个统一的视图中。

…我确实认为(有时很激烈)的讨论很有价值,仅仅是因为它们确实触及了非常重要的观点……

JAXenter:关于Eclipse MicroProfile的独立性的另一条评论:该想法是让MicroProfile采用Jakarta EE的新标准,并在有疑问的情况下,用其自己的组件替换它们。 毕竟这不会将MicroProfile降级到培养箱吗?

塞巴斯蒂安·达斯纳(Sebastian Daschner):我不一定同意,因为MicroProfile项目已经准备好投入生产并用于生产。 孵化器有时暗示某种技术还不成熟,例如Beta版。 现在,我们具有创新者地位的地方是,MicroProfile项目当然可以更快地推进和创新,对于整个Enterprise Java,我认为这是一件好事。

JAXenter:讨论将如何继续? 很快就这个问题做出决定吗?

塞巴斯蒂安·达施纳(Sebastian Daschner):是的,我确实希望我们能够在某个时候做出决定,但是,我确实认为(有时很激烈)的讨论是有价值的,仅仅是因为它们确实涉及了非常重要的观点,从命名和品牌角度来看。 那实际上是我的最初目标:不是用一个有思想的建议解决方案说服每个人,而是让每个人都参与进来,收集尽可能多的有效论据,然后看看前进的合理方法。 我确实认为现在是开始这项工作的好时机。

JAXenter:非常感谢!

翻译自: https://jaxenter.com/interview-jakarta-ee-microprofile-160454.html

 类似资料: