Java EE：更名实属无奈，未来路在何方？

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 处于停滞状态。

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 厂商（Red Hat、IBM、TomiTribe 和 Payara）来说：

他们在 JCP 中将拥有更多的话语权和影响力。

他们可以自由地访问测试套件，而之前它是属于 Oracle 的。

他们可以迭代推出“应用服务器”，不需要再承受 Java EE 新版本发布的“隧道效应”所带来的痛苦。

应用服务器的未来

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

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

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

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

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

对于开发者个人而言，参与 EE4J 是一个非常好的提升个人影响力的途径。推荐一个学Java的学习裙【六七八，二四一，五六三】，无论你是大牛还是小白，是想转行还是想入行都可以来了解一起进步一起学习！裙内有开发工具，很多干货和技术资料分享

王者风范

对于用户来说，目前的处境很艰难。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 开发者和用户，我们拭目以待。我的梦想，会成真吗？