今天釋出了 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 應該改變這一點！