今天发布了Java EE 6 提案 (JSR 316)。我相信这将是该平台自近 10 年前发布以来最重要的修订版，并且应该受到技术用户的欢迎。Interface21 很高兴成为该 JSR 的支持者，我期待为其做出贡献。

Java EE（在历史上大部分时间被称为 J2EE）在为 Java 中间件创造市场方面发挥了重要作用。然而，在这 10 年里，该平台出现了一些重要问题，例如：

• 符合 Java EE 标准的服务器需要臃肿地包含一系列功能，而这些功能绝大多数用户并不感兴趣
• 自 J2EE 设想以来，企业需求已经发生变化，而“一刀切模式”越来越不适用
• 企业 Java 已经因框架（特别是在开源领域）的出现而大大增强，这些框架使开发人员的生产力更高，其生产应用程序更高效且更易于维护
• 新的挑战，例如 Ruby on Rails，甚至 .NET，表明在快速变化和创新的时代，舒适的 2-3 年发布周期会危及整个平台

Java EE 6 是该平台的重要修订版，有可能解决所有这些问题。

它也可能解决另一个问题：如果 EE 供应商需要针对其大多数客户从未使用过的大量功能进行认证，这意味着他们很难跟上规范，稳定升级具有挑战性，而且——重要的是——Java EE 市场新进入者的可能性为零。最后一点令人担忧，因为 EE 服务器对现有厂商来说是一个舒适的特许经营权，这不符合用户的利益。为了证明发布新平台的困难：就我所知，目前BEA是唯一获得 Java EE 认证的市场领导者之一，尽管 Java EE 5 规范已经定稿数月。而 Java EE 5 中最有价值的新部分，例如 JPA，在 WebLogic 中早已准备就绪，但由于围绕某些技术（大多数 WebLogic 用户可能永远不会接触）的问题尚未解决，因此无法在 GA 产品中发布。

我的解释就到此为止：让我们直接看看提案，听听原始来源怎么说

在过去 8 年中，Java EE 平台已经成长和成熟，现在能够满足广泛的企业和 Web 应用程序开发需求。此外，Java EE 平台还培育了一个充满活力的社区和市场，用于与平台协同工作的附加技术、框架和应用程序。其中一些提供了平台中缺失的功能。另一些则提供了平台功能的替代方案。本次发布的主要主题是将这些技术作为整体 Java EE 生态系统的一部分加以接纳和支持，同时继续简化平台，以更好地针对更广泛的开发人员。为此，我们为本次发布提出了两个目标——可扩展性和配置文件。

几年前，这会被认为是异端邪说。我当时就是个异端，但我从未想成为异端。Java EE 终于开始考虑更宏观的景象，而不是幻想它能为所有用户需求提供一个好的解决方案。通过 Java EE 6，EE 平台在一定程度上被重新诠释为支持各种解决方案选择的中心点：一片沃土，让百花齐放。看到 Sun 内部这种更宏观的思维方式增长，令人鼓舞：想想他们对 JRuby 的接纳，以及认识到 JVM 和 EE 平台一样，是生态系统的基础，而不是绑定到单一语言。

Java EE 平台无限制地增长以包含 Web 和企业应用程序开发人员所需的所有有趣和有用的技术，这是不合适的。相反，我们认为有必要让更多这些技术能够干净地分层或插入到 Java EE 应用程序服务器中。通过增加更多的扩展点和更多的服务提供者接口，这些其他技术可以干净高效地插入到平台实现中，并且对于开发人员来说，就像使用平台内置功能一样容易。

再次，非常棒。服务器供应商长期以来一直利用一种谬论来混淆用户并阻止创新，即平台附带的技术比这些“有趣且有用”的技术与服务器基础设施“更好集成”。（幸运的是，几乎所有这些供应商早已停止这样做：例如，看看 IBM 在Spring 在 WebSphere 上认证中的作用）。

这里的关键是创新。有些技术自然以不同的速度发展：一方面，服务器基础设施和网络协议（变化相当缓慢，受益于标准化）；另一方面，在其之上运行的“有趣且有用”的技术需要以快得多的速度变化，而标准化在这方面基本上是失败的。

Java EE 平台的范围变得如此广泛，以至于失去了一些最初的重点。为了将 Java EE 平台重新聚焦于特定类别的开发人员和应用程序，我们提议引入 Java EE 平台配置文件（Profiles）。配置文件将引用通过 JCP 流程定义的 Java EE 平台，并且可能包含 Java EE 平台技术的一个子集、不属于基础 Java EE 平台的额外 JCP 技术，或两者兼有。除了定义基础 Java EE 平台之外，本规范还将定义在 Java EE 配置文件中引用 Java EE 平台技术的规则。

配置文件是一个巨大的进步。最终，用户将有权选择他们想要的东西，而不是在用户开始构建应用程序前两年由规范委员会认为他们想要的东西。是时候用健康的竞争取代苏联式的计划经济了。接着我的上一点：在之前的版本中，EE 平台试图有点像苏联的五年计划一样规定你如何构建应用程序，而在 EE 6 中，平台的作用更像西方国家法律框架的作用，确保人们可以作为个体自由竞争和行动，同时为了所有人的利益而同意游戏规则。

很明显，企业 Java 技术的用户已经确定了许多配置文件。例如，今天的 Web 应用程序、SOA 应用程序和金融中间件对服务器基础设施的需求截然不同，尽管 Java EE 的不同部分可以为它们提供价值。特别是，批量处理和无头中间件用户迄今为止已被 Java EE 忽视；最后，在 Java EE 6 的潜力范围内，他们看到了希望。

使用配置文件是解决 Java EE 平台不断膨胀问题的一种工具。同时，Java EE 平台中包含的一些技术也不再像刚引入时那样具有相关性了。需要有一种仔细而有序的方式来从平台中“修剪”这些技术，以最大限度地减少对使用这些技术的开发人员的影响，同时让平台变得更加强大。

我希望这一点能够得到贯彻。假设您拥有一台 Java EE 5 服务器（您的供应商可能在可接受的时间范围内提供或无法提供）。您是一个自豪的产品拥有者，它支持 EJB CMP 2.0 甚至 1.1。还记得 CMP 1.1 中的公共实例变量吗？您仍然可以享受它们。这是丑陋的史前遗迹，理应被遗忘，而不是让今天的产品变得臃肿。如果仍然有应用程序运行在这些东西上，它们可以在旧服务器上苟延残喘，直到有人终止它们的痛苦。

很高兴在提案中读到“EJB CMP - 被 Java Persistence 有效替代”。本次发布的一个重要主题是使 EE 在 2007 年的世界中更具相关性，而移除或使旧的失败方案成为可选是一种很好的表态，这给用户和向他们提供产品的供应商带来了实际的好处。

Interface21 期待与 Sun 以及 EE 6 伞形组织和相关专家组的其他公司和个人合作，使 EE 6 成为一个尽可能强大的平台。

正如我所说，我从未想成为一个异端。本质上，没有 EJB 的 J2EE（我与 Juergen Hoeller 合著）的愿景不是要贬低 J2EE，而是通过诚实地指出其中的糟粕以及标准化需要受到创新制约来帮助它繁荣发展。Java EE 6 提案似乎允许这种情况发生，我很高兴能够加入这个队伍。让我引用那本书中的一段话，其中大部分内容是近 4 年前写的。请注意，重点不仅在于批评 EJB，还在于强调 J2EE 的宏观景象才是真正重要的：

J2EE 仍然是一项相对年轻的技术。它的不完美并不奇怪。是时候回顾一下它的哪些方面奏效了，哪些方面不太奏效，以便我们能够消除消极因素，享受积极因素。由于 J2EE 内容庞杂，这本质上意味着找出提供最大价值的 J2EE 子集，以及一些我们需要用来最有效地利用它的补充基础设施。...您可能想知道，“没有 EJB 的 J2EE 还剩下什么？”答案是：非常多。J2EE 远不止 EJB。许多 J2EE 开发人员持不同看法，当他们在您的桌子上看到这本书时，会这样告诉您，但对 EJB 的作用以及 J2EE 的整体作用进行冷静分析表明，EJB 只是一个更大、更重要图景的一部分。J2EE 本质上是关于标准化一系列企业服务，例如命名和目录服务 (JNDI)、提供可能跨越不同事务资源的标准 API 的事务管理 (JTS 和 JTA)、连接遗留系统 (JCA)、资源池以及线程管理。J2EE 的真正强大之处在于这些服务，而这种标准化对行业做出了巨大贡献。

我相信，鉴于 Java EE 6 的目标，支持它与我在《没有 EJB 的 J2EE》及其他地方表达的关于 J2EE 的立场是一致的。例如，《没有 EJB 的 J2EE》的另一个核心主题是标准化应该扮演的角色，以及在哪些地方框架之间的竞争更有利于促进创新。

虽然开放（或至少部分开放）的规范流程是积极的，但我认为 J2EE 相对于 .NET 的最大优势之一在于 Java/J2EE 开源软件的丰富性……正如我们所见，关于 J2EE 架构的正统观点与实际经验不符。一些 J2EE 规范在较小程度上也是如此。我觉得我们正处于 J2EE 平台发展的一个重要十字路口。它显然需要进化和创新才能生存和繁荣。然而，基本企业基础设施（如 JTA、JAXB、JDBC 和 Java 语言本身）的规范意味着在如何访问该基础设施方面存在创新空间，而不会破坏一致、标准方法处理企业软件中最棘手的低级问题所带来的好处。

我在 2003 年写下这些文字时，并没有预料到 Java EE 专家组最终会使用“可扩展性”一词来表达同样的想法。这是一个惊喜。

我相信企业 Java 社区应该欢迎 Java EE 6，并应该欢迎 Sun 愿意与时俱进，做出能够增强整个企业 Java 平台的选择。J2EE/Java EE 有很多优点，但一些问题掩盖了它。Java EE 6 应该改变这一点！