转载

Jakarta EE：云原生Java的新平台

看新闻很累？看技术新闻更累？试试下载InfoQ手机客户端，每天上下班路上听新闻，有趣还有料！

在今年的 JAX大会上，Eclipse基金会的执行董事 Mike Milinkovich 专门介绍了新的Eclipse治理模型和 Jakarta EE 路线图。新的治理模型基于近期对全球1800多名Java开发人员的调查情况，并将聚焦于提供对微服务、云原生应用开发和加快版本发布周期等特性的支持。

在“ Java创新的未来 ”（The Future of Java Innovation）分会上，Milinkovich首次展示了众所期待的新Jakarta EE图标。该图标将用做新 Jakarta EE网站的标识。

Jakarta EE开发人员调查情况给出了三大关键领域：

更好地支持微服务；
与Kubernetes、Docker等的原生集成；
加速创新的步伐。

最近，Milinkovich就Jakarta EE未来的发展问题接受了InfoQ的专访。Milinkovich根据调查结果指出：

上述目标是由社区为我们设立的，我们对此也有很好的共鸣。这些目标的实现，也是我们认为开发人员希望给出的正确场景之一。我们收到的反馈清楚地表明，开发人员与我们在这些目标上是步调一致的。

Milinkovich进而指出：

首先要记住的是，我们正在将Java EE全部迁移到Eclipse基金会，并重命名为Jakarta EE品牌。Java EE将继续存在，为其提供的支持将截至当前的版本级别。而未来的全部工作，都将在Jakarta EE品牌下开展。

Java EE已被“财富”1000强企业在其基础设施中的某处使用，并且全球目前已有数百万的Java EE开发人员。因此，Java EE是一个非常重要的技术平台，它驱动了大部分的企业系统。

Milinkovich回忆了他在去年秋天 Oracle将Java EE的所有权转交给Eclipse基金会过程中的经历，并介绍了Jakarta EE的前进道路：

这是一次真正的旅程，最终，我们希望能够形成约40个新项目、具有约300位新的Eclipse项目提交者。Java EE的所有项目上线并在Jakarta EE下重命名，这其中的工作量非常大。

为了实现对Jakarta EE倡议的管治，我们成立了一个 Jakarta EE工作组。我们正在建立一种全新的规范流程，用于接管JCP在其中所发挥的角色，这同样也将是一项十分重要的任务。我们还需要做一些工作，找出Jakarta EE品牌的合规程序。目前来看，我们的开局不错。

InfoQ：正如在新闻稿中所述，“该管理Jakarta EE代码库的Eclipse顶级项目承诺将在2018年发布两个版本。” 这些版本是否存在着建议的时间表？

Milinkovich：事实上稍为微妙。我们承诺在今年推出两个版本，用于迁移到Eclipse的技术项目，分别称为Eclipse GlassFish 5.1和5.2。Eclipse GlassFish 5.1将首次由Eclipse基金会交付所有的项目。对于所有项目的上线而言，GlassFish 5.1将成为一个主要的里程碑。考虑到要使用原先的Java EE TCK，该版本将被认证为Java EE 8兼容。一旦发布该版本之后，我们将进而推出5.2版，并称之为Jakarta EE 8兼容。

因此，Jakarta EE规范的首个版本将与Java EE规范保持同一水平，并且目前看来，它们是相同或近乎相同。该过程只是迁移操作中的一部分，我们希望保持尽可能少的自由度。

交付与Jakarta EE 8兼容版本的重要意义，在于这表明我们将启动并运行所有的规范流程，部署到位所有的认证计划和法律协议，进而运行认证程序。

InfoQ：这是否存在一个给定的时间表？

Milinkovich：Eclipse GlassFish 5.1将于今年第三季度末推出，Eclipse GlassFish 5.2将于年底前通过Jakarta EE 8认证。

InfoQ：我们注意到，最近一轮的项目建议中包括GlassFish。

Milinkovich：是的，最近一批提案中包括了GlassFish，我们已经接近于完成。其实还有一点也是十分重要，但是对此人们尚未对此过多置评，那这就是开源所有TCK的项目建议。在我看来，一旦所有的TCK开源，这将成为一个非常重要的建议。

InfoQ：Jakarta EE是基于Java EE 8的，我说得没错吧？

Milinkovich：我们必须根据品牌并基于规范，仔细考虑那些开源相关的事情。Jakarta EE和Java EE一样，是一个依附于认证过程的品牌。因此，在声明WebSphere已通过Java EE 8认证之前，它必须通过Java EE 8测试。

类似的事情同样适用于Jakarta EE。但需要了解的重要一点是，这不仅仅是从Eclipse基金会交付开源代码。而且也是为了支持那些在Jakarta EE品牌下的专有的和开源的独立实现。

并没有任何供应商给出正式的通知。但就目前而言，我希望并期待有一天WebLogic发布将被命名为Jakarta EE，并被认证为Jakarta EE 8兼容。对于WebSphere、JBoss、TomEE等，同样也是如此。

InfoQ： Java EE、Jakarta EE和EE4J等命名容易让人产生混淆。您能向我们的读者解释一下其间的差异吗？

Milinkovich：Java EE是当前定义Java EE的一组规范。Java EE是在JCP流程下完成的，并且为了达到当前的版本级别，还将继续在市场上运行数年。因此，Java EE基本上已被置于“仅维护”模式。对于一位Java EE客户，其软件供应商将在未来几年中继续提供支持。

Jakarta EE将成为这一持续推进的技术平台的名称。该技术的未来版本及其规格将以Jakarta EE的名称和品牌发布。我们将要建立一种类似的流程，用于验证一个产品是否兼容Jakarta EE。为此，产品必须要通过一系列的测试。这些测试的出发点与Java EE相同，因为它们是由Oracle提供给Eclipse基金会的验证过程的组成部分。

EE4J仅仅是Eclipse基金会的一个顶级项目名称，大部分Jakarta EE项目运行于其中。通常情况下，我们很可能永远不会在引用项目时以EE4J为名称。未来，人们将称自己是一位Jakarta EE开发人员。EE4J仅是一些组织工件，用于表示如何在Eclipse基金会上运行项目。

Glassfish、Jersey、Grizzly、JAX-RS等技术的所有参考实现，都位于EE4J顶级项目之下。但是EE4J并非一个品牌，而仅仅是一个顶级项目的名称。导致这种混乱的原因在于我们尚未选定品牌的名称。所以，人们在一开始将其称为EE4J，因为这是人们手头唯一的命名。

很不幸，这种混淆持续存在。这是不可避免的。希望随着时间的推移，我们将不再听到EE4J。

InfoQ：Oracle是否将会继续持有Java EE品牌？

Milinkovich：Java EE和Java将仍然是Oracle持有的商标。如果你打算将某个项目以Java EE命名，那么就必须要与Oracle商谈如何使用该名称。你可能已经看得了一些持有争议性观点的文章，它们对Oracle持批评态度，因为Oracle并未将Java EE命名转交给Eclipse基金会。

我想要指出两点。第一，争议是永远不会发生的。人们从一开始就十分清楚，Java是Oracle的一个重要品牌，Oracle将会继续拥有Java的品牌。如果你了解大公司和商标法的内容，你就会明白这是事情总是这样的。

第二，事实上，我们将这次重命名看作是一件非常积极的事情，也是这项技术的一个绝佳机会。在许多开发人员的头脑中，Java EE总是意味着十数年前在内部部署的应用服务器。通过将该技术重命名为Jakarta EE，我们有机会去改变这项技术能力在开发人员的思想中的印象。所以，我非常高兴能做这次重命名。我认为，这对我们而言是重塑这项技术的一个契机，可使该项技术在开发人员头脑中重新定位，因而将具有更积极的前景。

InfoQ：这么说，聚焦于云原生特性绝对是一个好的出发点？

Milinkovich：确切地说，我预计随着技术的重点置于云原生和微服务上，很快还将会出现响应式。我们将尽快将这些重要的技术趋势加入到Jakarta中。这是一件十分新奇有趣的事情，因此我希望也确信，它们终将获得通过。并且从今年现在开始，会出现一些愿意尝试Jakarta EE的开发人员。

也许这些开发人员永远都不会考虑去尝试Java EE的某个新版本，因为在他们的印象中，Java EE并不会有助于问题的解决。所以我认为，对于Jakarta社区和技术而言，重命名是一个很好的契机。

InfoQ：鉴于Java EE 8处于“仅维护”模式，Oracle是否将不会进一步发展Java EE？

Milinkovich：是的。不会再有Java EE 9了。

InfoQ：很多应用不能运行在Java SE 9上，例如Payara、GlassFish、OpenLiberty等。但这已经发生了一些变化。例如，Data Geekery jOOQ的支持项目已模块化，Speedment去年启动了向Java 9的迁移过程。Jakarta EE最终是否会支持Java 9？

Milinkovich：我认为从某种程度上看，完全可以说Jakarta将支持Java 9。但很明显，Java EE的整个生态系统尚未实现代码的模块化，进而可以使用Jigsaw，所以仍有许多工作需要推进。

Java生态系统作为一个整体，必须要随时关注平台和语言的最新发展。我相信对Java 9的支持终将实现，但我并不清楚这将于何时发生，以及将在哪个发行版本中实现。它必须成为一个合理的优先事项，并且还有很多重要的事情需要完成。

InfoQ：当然，相比起实现Java 9支持，当前的事项要更为优先。

Milinkovich：部分原因在于对技术的采纳。如果我们翻看一下调查结果，就会发现与Java 8的采纳情况相比，采纳Java 9（当前是新发布的Java 10）的比例微乎其微。因此，我认为在Java 8的支持过期后，将在几年内看到更多的迁移。

目前，要让人们所具有的代码可完全适用于Jigsaw和模块化，还需要做大量的工作。所以，对Java 9的支持只是暂时搁置，直到迫不得已时才会启动。

同时，我认为压力主要在于移植那些基于Java构建的工具和框架。一旦客户和企业开始迁移基础架构中的各项零零碎碎，从IDE到日志记录，这种将整个Java生态系统迁移到模块化无疑是一项艰巨的任务。

InfoQ：在JDK 11中去除了Java EE和CORBA模块（即JEP-310）。这是否会对Jakarta EE产生某种影响？

Milinkovich：Java EE正在移交Eclipse基金会的过程中，其中将确保在SE和EE间给出绝对清晰的分离。部分泄漏到SE中的JTA规范，同样也被拒之门外。所以，这只是一些背景清理工作，与其它所有的工作是并行发生。

InfoQ： JDK已经采用新的“六个月发布”周期。Jakarta EE是否也有必要采用同样的发布周期？

Milinkovich：目前我们还不知道。依我个人的观点，这并不反映社区中任何技术牵头者的观点，就是Jakarta EE完全没有必要对Java SE亦步亦趋，去每隔六个月就推出一个新发布。

在我看来，创新的速度和节奏，取决于我们需要采取什么措施去实现云本地和微服务，去实现响应式。我认为在这些创新中，只有相对较少的一部分是与Java SE平台中的全新功能密切相关的。就此而言，我们会给出一个对我们自身有意义的发布节奏，因为企业迁移到新版本Java发展的速度，肯定要滞后于Java的发布速度。

目前，我尚未看到将Jakarta EE的发布节奏挂钩到六个月周期以与Java SE亦步亦趋这一做法的可取之处，尽管我们可能终将看到。我可以构想每六个月交付一次这样的场景，但这并不一定意味着我们每隔六个月就要推出一个新版本的Java。

如果企业和云计算框架都没有必要每隔六个月就转向最新最好的Java版本，那么我认为Jakarta EE也完全没有任何必要这样做。就像我曾说的那样，这是完全是我的个人观点。也许大家会看到，那些实际运作这些项目的技术人员会持完全不同的观点。

InfoQ：Eclipse基金会是否与云原生计算基金会（CNCF）具有一定的工作联系？

Milinkovich：公平起见，可以说是我们希望与CNCF建立工作联系。我们正在与CNCF就我们在构建物联网中使用的一些技术上建立工作关系。我们的目标是确保Jakarta EE能以平台形式，尽可能强壮地运行在Kubernetes和Docker生态系统上。这样，我们就可以与CNCF开展合作，共同讨论双方的需求。

我认为这对我们双方而言都是一个很好的机会。很明显，Kubernetes在工业界具有很好的发展势头，因为Kubernets不仅为人们提供了将工作负载从云到云服务提供商转移出来的能力，而且也提供了从本地云基础设施转移到公共云基础设施的能力。Kubernets为人们提供了很大的部署灵活性。

与此同时，Java是企业中最重要的语言平台。因此我认为，这两种技术的紧密结合程度，不仅有助于双方为企业采纳云计算提供帮助，而且还充分地利用了数百万开发人员的技能，并帮助他们将自身的技能推向该新技术领域。