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

InfoQ：这是否意味着 Eclipse 基金会和 CNCF 需要以成员方式相互参与到对方的组织中？

Milinkovich：我们可能会那样做，但我们和 CNCF 都并非以收费服务（Pay-to-play）模式运行的基金会。这不是我们要做的事情。但我认为，这给出一种很好的姿态，使得我们双方都可以公开表明，我们正开展合作，并具有很好的合作基础。

相关资源

• Ivar Grimstad 撰写的文章“ Jakarta EE、EE4J 和 Java EE 的关系”，2018 年 3 月 26 日。
• Will Lyons 撰写的博客“ 背景资料：Oracle 对 Jakarta EE 的贡献”，2018 年 4 月 24 日。
• David Delabassee 撰写的博客“通向 Jakarta EE 之路”，2018 年 4 月 24 日。
• Fujitsu 公司网站上的文章“ Eclipse 基金会已建立 Jakarta EE 工作组”，2018 年 4 月 24 日。
• Mark Brewer 撰写的博客“支持 Jakarta EE 对加速云原生 Java 的请求”，2018 年 4 月 24 日。
• Ian Robinson 撰写的文章“ Jakarta EE：企业级 Java 的新平台”，2018 年 4 月 24 日。
• Mark Little 撰写的文章“ Jakarta EE 正式推出”，2018 年 4 月 24 日。
• Debbie Hoffman 撰写的博客“ Jakarta EE：云原生、开源 Java 的未来所在”，2018 年 4 月 24 日。

查看英文原文： Cloud Native Java Has A New Home: Jakarta EE