jakarta ee_Java EE如何成为Jakarta EE的新生命

jakarta ee

这篇文章的标题可能看起来很奇怪，但是如果您对Java EE的近期历史有所了解，那将是有道理的。

最初，Sun启动并运行Java Enterprise Edition ，后来Oracle在收购Sun后接管了它。 规范是由Sun / Oracle管理的流程驱动的。 他们或多或少定期地提供了该规范的新版本，该规范的新版本由服务器供应商实施。 这些供应商必须获得Oracle的技术兼容性套件（TCK）和品牌的许可。

让我们快进一点。 2013年，Java EE 7发布，Oracle开始使用EE8，但进展并不很快。 同时，诸如Docker和Kubernetes之类的新技术应运而生，并改变了应用程序的运行方式。 现在，该软件不再是在大型计算机上运行单个胖服务器进程，而是分成了多个较小的独立服务，这些服务在由Kubernetes精心组织的（通常）Docker容器中运行。

为了充分利用运行软件的新方式，需要进行一些更改   被需要的软件和项目的设置。 术语“云原生”诞生了，并创建了由12个因素组成的方法来描述这些新要求。 引用一个因素 ：

三， 设定档

将配置存储在环境中

在规范中，没有很好的统一方法来实现此目的，并且每个开发人员都必须以临时方式来做到这一点。

Enterprise Java社区看到了这些变化和挑战，并希望利用它们，但是Java EE 7并没有解决这些变化和挑战，而且Java EE 8发行版也不见了。 在社区中，Oracle似乎对Java EE失去了兴趣，关于传福音人员被解雇，而开发人员被转移到Oracle内部其他软件项目的报道也无济于事。

为了克服此限制并使Java EE适应新的世界，包括伦敦Java社区，Red Hat，Payara，IBM，SouJava，Tomitribe等其他感兴趣的团体在2016年开始了MicroProfile的工作。MicroProfile的目的是开发缺少的云本机功能，这些功能可能会包含在将来的Java EE版本中。

而且，仍然没有Java EE 8。

搬到雅加达

MicroProfile移至Eclipse Foundation，并发布了多个版本，其中一个发布就在2017年的JavaOne会议之前，当时Java EE 8突然发布了，但并没有真正解决云原生需求。

2017年9月，在JavaOne之后和就在EclipseCon Europe之前，Oracle宣布将Java EE捐赠给Eclipse Foundation。 这是一个革命性的举措，因为Oracle不仅包括规范，而且还包括规范过程和以前秘密的TCK。

同时，成立了一个项目管理委员会（PMC）来指导该过程。 在2018年2月下旬，委员会宣布了一个新的品牌名称： EE4J 。 （对于那些回想起Jakarta是Apache Foundation的一组Java项目的人们：是的，这不是冲突，而是友好的复兴，正如PMC成员和Tomitribe创始人David Blevins所描述的那样 。

下一步是建立各个委员会，并且对我们这方面的极客来说最重要的是创建徽标。 在找到一个开源的方式标识不违反商标是不容易的，也参与了一些kerfuffle的整个过程，但没有什么不能被解决。

最终，在4月24日，新的Jakarta EE标志和网站揭晓。

Jakarta EE现在正在吸引新成员，像Microsoft甚至Pivotal（Spring）一样，没人怀疑对此生态系统感兴趣。

如果您对命名有疑问，特别是EE4J与Jakarta EE，那么简单的答案是：“始终使用Jakarta EE”。 PMC负责人Ivar Grimstad 很好地总结了争议 。

下一步是什么？

Jakarta EE的第一项努力（自Oracle宣布将Java EE提交给Eclipse以来一直在进行）是能够从Jakarta EE来源完全构建Java EE 8兼容服务器。 在实现此目标之后，可以全力开发新功能。

Eclipse基金会的负责人Mike Milinkovich在Jaxenter.com上的一次采访中（在2:30和11分钟之间收听）分享了他的观点。

那MicroProfile呢？ MicroProfile和Jakarta EE社区已经有很大的重叠，因此，预计在Jakarta EE 8之后，社区将决定它们如何一起工作。 我认为MicroProfile可以作为Jakarta EE的孵化器。 这将允许在MicroProfile中快速开发和完善新功能。 之后，它们将被提升为雅加达EE级规范，并在更长的时间内保持更稳定的状态。

翻译自: https://opensource.com/article/18/5/jakarta-ee

jakarta ee