今天发布了 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 在WebSphere 上认证 Spring中所扮演的角色）。

这里的关键在于创新。一些技术自然会以不同的速度发展：特别是，一方面是服务器基础设施和通信协议（变化相当缓慢，并受益于标准化）；另一方面是“有趣且有用的”技术，它们需要以快得多的速度发展，而标准化在很大程度上未能跟上。

Java EE 平台的覆盖范围变得如此广泛，以至于失去了一些最初的焦点。为了重新聚焦 Java EE 平台于特定类别的开发人员和应用程序，我们提议引入 Java EE 平台配置。配置将引用 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 平台。

正如我所说，我从未想过要当异端。本质上，《 J2EE without EJB》（我与 Juergen Hoeller 合著）的愿景并非要抨击 J2EE，而是要通过诚实地指出问题并认识到标准化需要创新来制衡，从而帮助其蓬勃发展。Java EE 6 提案似乎允许这种情况发生，我很高兴能加入这个行列。让我引用那本书中的一段话，其中大部分内容是在近 4 年前写成的。请注意，重点不仅在于批评 EJB，还在于强调 J2EE 的宏观图景才是真正重要的。

J2EE 仍是一项相对年轻的技术。不完美并不令人意外。是时候盘点一下它在哪些方面做得好，哪些方面做得不太好，以便我们能够消除负面因素，享受正面因素。由于 J2EE 包含的内容很多，这基本上意味着要确定最有价值的 J2EE 子集，以及一些我们需要的补充基础设施，以便最有效地利用它……您可能会问：“没有 EJB 的 J2EE 还剩下什么？”答案是：很多。J2EE 远不止 EJB。许多 J2EE 开发人员持有不同看法，当他们看到您桌上的这本书时会告诉您，但对 EJB 的功能以及 J2EE 的整体功能的冷静分析表明，EJB 只是一个更大、更重要图景的一部分。J2EE 本质上是关于标准化一系列企业服务，例如命名和目录服务 (JNDI)、可能跨越不同事务资源的事务管理（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 应该改变这一点！