今天发布了 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 的接纳，以及认识到，与 EE 平台一样，JVM 是生态系统的基础，而不是与单一语言绑定。

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

同样，这很棒。平台附带的技术比这些“有趣且有用的技术”与服务器基础设施“更好地集成”的谬论长期以来被服务器供应商用来迷惑用户并阻止创新。（幸运的是，他们中的几乎所有人都很久以前就停止了这样做：例如，考虑 IBM 在 Spring 在 WebSphere 上获得认证 中发挥的作用）。

这里的关键是创新。某些技术自然以不同的速度发展：特别地，一方面，服务器基础设施和线协议（变化相当缓慢，并且受益于标准化）；与构建在其之上的“有趣且有用的”技术相反，这些技术需要以**更快的**速度变化，并且标准化在很大程度上未能实现。

Java EE 平台的影响范围已变得如此广泛，以至于它失去了一些最初的重点。为了将 Java EE 平台重新聚焦于特定类别的开发人员和应用程序，我们建议引入 Java EE 平台配置文件。配置文件将引用由 JCP 过程定义的 Java EE 平台，并且可能包括 Java EE 平台技术的子集、非基本 Java EE 平台的其他 JCP 技术或两者兼而有之。除了定义基本 Java EE 平台外，此规范还将定义在 Java EE 配置文件中引用 Java EE 平台技术的规则。

配置文件是一项巨大的进步。最终，用户将有权选择他们想要的东西，而不是规范委员会在用户开始构建应用程序前 2 年认为他们想要的东西。是时候用一些健康的竞争来取代苏联式的计划经济了。继续我之前的一点：在之前的版本中，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 持久性有效地取代”真是太好了。关于此版本的主题是使 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 的目标，支持它与我在《J2EE without EJB》和其他地方表达的关于 J2EE 的立场是一致的。例如，《J2EE without EJB》的另一个核心主题是标准化应该发挥的作用，以及在哪些情况下框架之间的竞争更有利于促进创新。

虽然开放（或至少部分开放）的规范流程是积极的，但我认为 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 应该改变这一点！