从更名为Jakarta EE的无奈之举看Java EE的开源之路

java| 2018-03-12

1999 年，Sun 公司正式发布了 J2EE 的第一个版本。到现在，Java EE（2006 年 J2EE 改为为 Java EE）算起来已经有 19 年的历史了。在过去的这些年里，Java EE 曾经引领并深深影响了企业级 Web 应用开发以及相关标准，可以说也是世界互联网技术发展历史上的一个重要技术。

2017 年夏天，Oracle（Sun 公司早已被 Oracle 收购）表达了想要开源 Java EE 的意图，紧接着又宣布希望将 Java EE 移交给 Eclipse 基金会管理，这被很多开发者认为是 Java EE 发展的重要里程碑之一。因为后面这些年，Java EE 的开发已经跟不上时代变化，并且迭代速度已经到了让人难以忍受的地步。这也许是 Oracle 求变的方式之一。

紧接着在 2017 年的 10 月，Eclipse 基金会表示正准备将 Java EE 基于 Eclipse Public License 2.0 许可协议，并作为 Eclipse Enterprise for Java（EE4J）项目进行开源，包括 Oracle、RedHat、IBM 等项目都会参与其中。

但是，接下来的进展看起来并不好，也在意料之中，在我（InfoQ 编辑）理解来看冲突还主要是 Oracle 商业利益以及开源社区之间。其实，Oracle 在 2017 年 9 月宣布将 Java EE 所有权转交给 Eclipse Foundation 时，曾明确表示希望 Java EE 重命名。

Java EE 守护者也担心 Oracle 会限制使用 EE4J 中的“Java”和“javax”相关的包名（不了解的同学可以看看 Google 和 Oracle 的官司）。所以昨天聊聊架构也报道了 Java EE 将会重命名为 Jakarta EE 的消息，并且为了避免法律风险，包换也有可能会对应更换，甚至包括类和接口（还没有得到确认，还在讨论中）。

前段时间，Java EE 守护者 Jean-François James 撰写了系列文章，来探讨未来 Java EE 的发展方向，InfoQ 为了帮助大家了解这个项目目前的进展以及状态，同步进行了翻译。以下为全文。

Oracle 开源 Java EE 的动机

据 Oracle 的 Java EE 布道师 David Delabassee 透露，Oracle 之所以要开源 Java EE，主要是想让它变得更敏捷，以适应快速发展的行业和技术需求。

事实上，尽管 JCP（Java Community Process）也在这方面做出了一些努力，但仍然无法赶上现代 IT 市场快速发展的步伐。从 2013 年 6 月发布 Java EE 7 以来，出现了很多新兴技术，比如 NoSQL、容器、微服务和无服务器架构，但它们都未能被包含在 Java EE 当中。

在我看来，这一决定显得有点唐突，因为它与 Oracle 在 JavaOne 2016 上发布的路线图完全背道而驰。

当然，这一决定也表明了 Java EE 不再是 Oracle 的首要关注点。Oracle 似乎把更多的注意力放在新的开源项目 Fn 上，Fn 是一个无服务器框架，类似亚马逊的 Lambda 和 IBM 的 OpenWhisk（现在是 Apache 项目）。

2017 年 9 月 21 日，Java EE 正式发布。我们先来看看 Java EE 8 的主要变更。具体如下：

与 Java SE 8 同步：DateTime API、CompetableFuture 和可重复注解。
CDI 2.0：异步事件、事件保序以及与其他规范更好的集成。
Servlet 4.0：支持 HTTP/2（服务器端推送）。
JAX-RS 2.1：服务器端发送事件、反应式扩展。
JSON Processing 1.1 和 JSON Binding 1.0。
安全：简单化、秘钥管理、现代化、OAuth2 和 OpenID 支持。

总的来说，Java EE 8 更像是大跃进，而不是小步快跑。不过，云原生相关应用并没有包含在 Java EE 8 中，如分布式跟踪、集中式配置、健康监测、回路断路器、负载均衡。

Java EE 的现状是怎样的？

对于大多数企业来说，Java EE 仍然是一个非常有价值的平台：

完善而灵活的编程模型。
单一的依赖管理：通常一个 Maven 的 pom.xml 不会包含超过 20 行配置代码，即使项目很复杂。
CDI 易用且强大。
可以与大多数 IDE 集成。
有很多轻量级的应用服务器，比如 TomEE、Payara、Red Hat Wildfly 和 IBM Liberty，它们不仅启动速度快，而且占用资源小。
可以使用 Java EE 来开发容器化的微服务，虽然不完美，但也不失为一种选择。

在我看来，Java EE 的不足在于：

不够先进：尽管它还有一定的价值，但大部分开发者并不会将它作为开发云原生应用的首选。
因为组件模型的差异，缺乏整体的一致性：Servlet、CDI、EJB……确切点说，CDI 和 EJB 之间的界限有点模糊，或许 CDI 在未来会成为“第一类公民”。
测试相对复杂。
规范及其实现的演进速度较慢。
与 Java SE 不同步：要想在 Java EE 中看到 Java 9 的模块化系统尚需时日。

Java EE 生态系统的演化

Oracle 的决定给整个 Java EE 生态系统带来重大影响。

Oracle

作为 Java 技术（包括 Java EE）和品牌的所有者，Oracle 仍然会继续负责维护 Java EE 8。

但这种所有权在品牌和未来的技术发展方面存在一些限制，比如：

不能再使用 Java EE 作为品牌名称。
在新名称中使用 Java 要经过多方讨论和允许。
不能再使用 javax 包名。

JCP

JCP 旨在“为 Java 技术制定标准技术规范”。但 JCP 几乎为 Oracle 所掌控：项目管理办公室、选举、投票、规范管理等等。从组织角度来看，JCP 是开放的，它欢迎任何人加入，IBM 和 Red Hat 就是非常重要的成员。同时，JCP 涵盖了 Java EE 中的很多规范，如 Servlet、EJB、CDI、JAX-RS……

其中每个规范都是以 JSR（Java Specification Request）的形式进行管理的（比如 Java EE 8 对应 JSR 266，Servlet 4.0 对应 JSR 369，CDI 2.0 对应 JSR 365，CDI 2.1 对应 JSR 370），并由专家组负责管理每个规范的生命周期。

专家组要交付三个方面的内容，包括规范文档、规范的参考实现以及测试套件。

从外部来看，这个流程太过笨重：从规范的启动到最终发布需要很长时间，而应用服务器实现规范也需要一些时间。

从内部来看，作为 JCP 的成员，我不得不承认，JCP 的监管质量和人们的投入程度给我留下了深刻印象。或许它的步子迈得不够快，但话说回来，在制定一个标准时，创新又占有多大比重呢？

EE4J 最为成功的一个方面在于它的敏捷性，它能够很快建立起强壮且灵活的监管模型。

Java EE Guardians（我把这个词翻译为守护者）

Java EE Guardians 由“一群致力于通过社区和拥护者来推动 Java EE 平台发展的草根组成”。Reza Rahman 在 2015 年成立了 Java EE Guardians，旨在催促 Oracle 重启 Java EE 8，因为当时的 Java EE 8 处于停滞状态。

该组织目前专注于保护 Java EE 品牌和 javax 包，让它们得以延续，他们在 2018 年 1 月份发表的一封公开信中说明了他们的目的。具体如下：

https://javaee-guardians.io/2018/01/02/joint-community-open-letter-on-java-ee-naming-and-packaging/

Microprofile.io

Microprofile 把自己定义成“一个基准平台，以微服务架构为基准来优化企业版 Java，并交付可在多个 Microprofile 运行时上运行的应用程序”。它从 2016 年夏天启动，现在已经成为了 Eclipse 的项目，最初贡献者包括 TomiTribe、IBM 和 Payara，Oracle 也在 2017 年 11 月加入其中。

Microprofile 的第一个版本在 JavaOne 2016 上发布，涵盖了 JAX-RS 2.0、CDI 1.2 和 JSON-P 1.0。

从那以后，社区同时开始了多个项目，包括：

microprofile-config
microprofile-fault-tolerance
microprofile-health
microprofile-metrics
microprofile-open-api
microprofile-jwt-auth

Microprofile.io 的最初目标是专注于 JCP 标准的快速创新，而现在也可以被认为是 EE4J 在社区、组织和监管方面的“POC（概念性验证）”。

Microprofile.io 的未来将去向何处？与 EE4J 合并抑或是继续保持独立？现在还没有定论。

EE4J

EE4J 的章程上写道：“Eclipse Enterprise for Java（EE4J）是一个开源倡议，旨在建立和实现标准 API，为 Java 运行时提供技术工具，促进服务器端和云原生应用的开发、部署和管理。EE4J 以 Java 平台和 Java EE 标准为基础，并在 Java EE 8 的基准上建立新的标准”。

需要注意的是，EE4J 只是项目的名称，而不是一个品牌。2017 年 11 月份，他们为寻找合适的品牌名称进行过一次问卷。但因为受到上述的一些限制，至今未达成共识。不过，社区当中有 79% 的人似乎希望能够保留 Java EE 这个品牌。

2017 年 11 月，项目管理委员会成立，成员来自原先的 Java EE 生态系统。委员会的首要任务是完成过渡、建立新的社区，以及基于 Java EE 8 发布第一个版本。

目前有两个项目正式成为 EE4J 的一部分：

Yasson：JSON-B 的参考实现。
EclipseLink：JPA 的参考实现。

开源（Java EE）对于 Java EE 厂商的影响

对于 Java EE 厂商（Red Hat、IBM、TomiTribe 和 Payara）来说：

他们在 JCP 中将拥有更多的话语权和影响力。
他们可以自由地访问测试套件，而之前它是属于 Oracle 的。
他们可以迭代推出“应用服务器”，不需要再承受 Java EE 新版本发布的“隧道效应”所带来的痛苦。

应用服务器的未来

新的 Java EE 会成为“保护伞”抑或是由一系列独立的规范组成？

由此引申出的问题是：应用服务器会继续扮演“单体平台”的角色，还是会变成可组合的模块平台？

我倾向于选择第二种可能，Red Hat 的 Wildfly Swarm 就是最好的例子。

开源 Java EE 对开发者社区的影响

对于开发者社区来说，这是一个很好的机会，他们需要一个敏捷的平台来促进创新。

对于开发者个人而言，参与 EE4J 是一个非常好的提升个人影响力的途径。

王者风范

对于用户来说，目前的处境很艰难。Java EE 的优势在于一系列由 JCP 推动的官方标准，而依赖这些标准对于长期项目来说是至关重要的。

Java EE 的上一个阶段已经走到了尾声，不管高兴与否，我们都要继续与它共同前行。新的 Java EE 标准将为我们带来什么？没有了 JCP 的支持，EE4J 将如何发展？

这一切要取决于行动的快慢和实际结果的产出。我粗浅地认为，这将受到以下几个因素的影响：

时间：之前已经提到，尽管 Java EE 8 仍有它的价值，但它并不是最先进的，所以它需要尽快缩小差距，以便在竞争中胜出。如果 EE4J 要花几个月“才能”交付一个版本，那么要实现这个目标就会很困难。
与 Microprofile.io 协作：Microprofile.io 已经在云原生应用方面发力，所以完全可以利用它，把它集成到 EE4J 中。
社区：EE4J 社区将发展壮大到怎样的程度？
还是时间：厂商和开源项目是否有能力及时交付符合 EE4J 规范的平台？Java EE 最大的一个问题就是从规范最终版的发布到应用服务器的实现需要很长的时间。

不过，就像昨天文章中评论的那样，不管名字是否改变，面对 Spring 框架的强力冲击，Java EE 路在何方，现在还不好说。从目前社区热点来看，我只知道，Spring Boot、Spring Cloud 这套框架很受欢迎。

对于 Spring 生态和 Java EE 的关系，Jean-François James 也做了评论（另外一篇文章）。

Java EE 和 Spring 之间复杂的关系

在之前评估 Java EE 生态系统对 EE4J 发展的影响时，我漏掉了一个非常重要的因素：Pivotal 和它的 Spring 框架。

Java EE 和 Spring 之间的关系已经进入了“最好的敌人”模式。

Spring 诞生于 2004 年，由 Rod Johnson 发起，作为对 J2EE（Java 2 Platform，Enterprise Edition）和 EJB 2 复杂性的反击。从那个时候开始，Spring 和 Java EE 之间就没有停止过竞争，并彼此影响对方：

Spring（以及 Hibernate）的出现刺激了 Java EE 社区，促使他们推出了 EJB 3 和 JAP 1.0。
Spring Batch 直接影响到了 Batch 规范（JSR 352）。
Spring Dependency Injection 启发了 CDI（Context and Dependency Injection）。
Spring 恰到好处地使用了 J2EE 和 Java EE 中的某些标准，如 Servlet、JMS 和 JPA。
Spring 5 宣称兼容 Java EE 8。

从诞生之日起，Spring 就因为超强的实用性受到了开发者的青睐，而且它的演进速度很快，可以快速地集成新技术：NoSQL、AMQP、微服务、云原生应用……

从 2006 年开始，Java EE 也将提升易用性和对开发者的友好放在首位，但在演进速度方面还是很慢，主要有两个原因：

JCP 制定规范需要很长时间：即使是一个轻量级的规范，也需要多方参与，需要更长的时间才能达成一致。
实现和认证：在规范发布之后，需要几个月时间才能找到符合认证的应用服务器。

而最近，这方面的差距在加大：

Spring Boot 将“以约定代替配置（Convention Over Configuration）”的原则发挥到了极致，进一步提升易用性。
Spring Cloud 利用 Netflix 的开源组件解决了与云原生应用开发相关的问题，如服务注册、服务发现、弹性、负载均衡、监控……
Spring 5 将反应式编程提升为一等公民。

Java EE 在这方面的速度要慢的多。在 2013 年发布 Java EE 7 之后，经历了一段消停期。2016 年，在社区的压力下，Oracle 才发布了一个新的路线图。

Java EE 8 发布于 2017 年 9 月，虽然人们对其期望甚高，但并非革命性的。人们还是把更多的目光投向了 Java EE 9，期望下一个版本会有更多的创新。

与此同时，Eclipse 基金会于 2016 年中启动 Microprofile.io 项目，旨在以微服务架构为基准来优化企业版 Java，以此来推动 Java EE 生态系统的发展。Microprofile 1.0 涵盖了 JAX-RS 2.0、CDI 1.2 和 JSON-P 1.0，1.2 版本于 2017 年 9 月发布，加入了更多特性，如配置、容错、JWT、度量指标和健康检测，2.0 版本有望与 Java EE 8 看齐。

过渡到 EE4J

EE4J 旨在提供一种更加灵活的协作方式，但要成功，有一些前提是不可或缺的：

Java EE 8 遗留资产的转移（规范文档、参考实现和测试套件）。据 David Delabassee 所述，这项工作已经在进行当中。
建立新的监管模型和操作系统，在最近发布的工作组章程中已经提到了这一点。
建立活跃的社区。
品牌和包的重新命名：Oracle 不允许 EE4J 在新规范中重用“Java EE”这个商标和 javax 这个包名，所以需要重新起一个名字。

在满足了这些条件之后，EE4J 就可以继续演进，适应云原生应用和 Java SE 平台（特别是 Java 的模块化系统）的变更。

大一统的时机？

除了监管和技术之外，EE4J 必须为自己找到合适的位置，因为没有了 JCP 的支持，它作为标准的地位就不复存在。在这样的情况下，EE4J 已无力与 Spring 展开竞争。或者说，整个 Java 生态系统经不起这样的“内战”。Java 在应用服务器方面的霸主地位已经一去不复返，它必须与其他平台展开竞争，比如 Node.js、Go 和 Python。如果能够将整个社区甚至整个行业的力量带动起来，那就更好了。

为什么不呢？如果 EE4J 能够推出一些独立的兼容规范，Spring 团队就可以参与进来，让 Spring 成为 EE4J 的主要参与者。

作为 Java 开发者和用户，我们拭目以待。我的梦想，会成真吗？

本文文字及图片出自 InfoQ