最近，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