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