你可能還記得 AMC Gremlin——它強有力地競爭著“史上最醜汽車”的稱號。Gremlin 是上世紀 70 年代生產的，但現在仍能看到一些，就像我去年在舊金山拍下的這輛一樣。

如今的企業級 Java 體驗讓我想起了這個美國汽車工業的遺產。Gremlin 是對石油危機的無奈回應。AMC 需要一款“緊湊型”汽車，於是他們拿來了現有最小的汽車，然後將其砍掉一半。最終的結果出人意料地賣得很好，但也明顯暴露出其前部和後部是由不同團隊匆忙拼湊而成的跡象。毋庸置疑，最終在小型車轉型中勝出的是日本和歐洲製造商。

Java 中的 Gremlins

如今，企業級 Java 的感覺非常像 Gremlin，並且在生產力方面是一個主要問題。無論是從底層到頂層堆疊，還是貫穿整個應用程式生命週期，各個部分都是由不同來源拼湊而成的。雖然大部分元件本身都很好，但有些對於典型場景來說卻過度複雜。遺憾的是，我們已經習以為常，並對由此帶來的生產力後果感到無可奈何。例如，通常情況下，需要使用開源構建工具（Ant 或 Maven）構建應用程式；使用來自不同專案或供應商的 IDE，手動整合眾多外掛；圍繞開源框架進行應用程式架構設計；然而卻部署到來自另一家供應商的應用伺服器上——這種整合往往相對膚淺。

場景中的一些部分幾乎是既定的：比如 Spring 和 Hibernate、基於 Eclipse 的工具集，以及（越來越多地使用的）Apache Tomcat。但整體上既依賴於開發人員為每個專案做出大量選擇，也依賴於大量的內部粘合和支援——後者是我們忽略或無奈接受成本後果的另一個領域。

不必非得如此

其他平臺的經驗表明了系統化思考的好處。Ruby on Rails 之所以能取得很高的生產力，很大程度上是因為它提供了整合的體驗；它替開發者做出了選擇，例如，構建過程與應用程式框架緊密結合。Rails 從應用程式框架建立程式設計模型的前提開始，這有助於為一個連貫的理念奠定基礎。

微軟也提供了一個很好的例子。微軟將從 Visual Studio 到 SQL Server（甚至包括 Azure 雲）的所有東西都視為一個整體願景的一部分，雖然不是所有的組成部分都盡善盡美，但其結果是提供了比企業級 Java 更具整合性的體驗。

當然，這兩個例子都不是完美的。Ruby on Rails 在一定程度上犧牲了處理複雜場景（例如使用遺留資料庫）的能力來獲得生產力。微軟的成功是透過壟斷實現的。當一家公司控制所有部分時，更容易實現整合化的結果。

幸運的是，開源提供了以更加開放的方式實現同樣結果的機會。雖然沒有哪個單獨的開源專案能解決完整的應用程式生命週期問題，但供應商可以大量借鑑開源專案來構建整合化的體驗，從而最大限度地減少供應商鎖定。在開源基礎上構建，也允許供應商在每個領域選擇市場領先的解決方案，而不是像 AMC 那樣，從自家零件庫裡拼湊產品。

不僅僅是開源

然而，單靠 開源並不能解決問題。開源專案通常擅長解決軟體堆疊或生命週期中的特定問題；但它們不太擅長（也興趣不大）整合所有部分。一個能解決應用程式整個生命週期宏觀問題的現代解決方案，必然會基於開源，但需要供應商的支援。

令人驚訝的是，在 Java 領域，似乎沒有哪家供應商挺身迎接這一挑戰，甚至很少有嘗試過。儘管 Sun 控制著 Java 規範，但它從未成為一個強大的企業級 Java 供應商，而且似乎從未完全理解 Java 中的生產力問題。（此外，生產力問題通常透過 產品 而非規範來解決。直到最近，或許為時已晚，Sun 才開始在 Java 領域意識到這一點。）IBM 確實擁有涵蓋整個生命週期的解決方案，但在 IBM 的案例中，擁有一個連貫的願景並不能彌補大多陣列成部分生產力特性較差的問題。任何以 Rational Application Developer 起步、以 WebSphere 為核心的軟體生命週期解決方案，都不太可能提供現代化的生產力體驗，或使 Java 與競爭平臺抗衡。微軟，儘管有很多缺點，但在理解開發人員的需求和願望方面，比任何傳統的企業級 Java 供應商都要深入得多。

企業級 Java 領域的老牌供應商也對造成最初諸多生產力問題的複雜性負有責任，因此它們不太可能是解決這些問題的最佳人選。此外，尤其是在行業最近整合之後，它們都是龐大的公司。龐大的公司通常不追求簡潔性——而且，這樣做往往不符合它們的利益。

展望未來

Java 需要一個新的旗手，而它不會是現有任何一家。SpringSource 致力於改變企業級 Java 的體驗——我們有能力實現這一點。

Spring 和 SpringSource 一直專注於消除企業級 Java 的複雜性。“消除企業級 Java 複雜性”現已成為我們的公司口號。為此，我們已努力工作了 6 年多。Spring 最初透過創新最大限度地降低企業級 Java API 的複雜性，但很久以前就開始應對更廣泛的挑戰——例如安全、批處理、整合和 Web 服務——而 SpringSource 作為一家公司也比 Spring 更廣闊。憑藉 Spring、Grails、Spring Dynamic Modules 和 SpringSource dm Server 以及對 OSGi 的簡化，SpringSource 早已為提高企業級 Java 的生產力設定了方向。

消除企業級 Java 的複雜性意味著考慮應用程式生命週期的每個階段。這不僅僅是一個伺服器或應用框架，無論它有多好。很難想象任何一個不嚴重依賴 Spring 的現代完全整合解決方案，但 Spring 只是全貌的一部分。

構建、執行、管理

全面提升生產力涉及考慮生命週期的三個關鍵階段：構建階段（應用程式開發時）、執行階段（應用程式部署到伺服器時）和管理階段（應用程式在生產環境中維護時）。

這種關注點解釋了為什麼我們現在是 Grails 背後的公司——這是 JVM 上生產力最高的技術；也解釋了為什麼我們構建了 SpringSource Tool Suite 來幫助加速使用 Spring 進行企業級 Java 開發。

這解釋了為什麼我們進軍其他領域，例如應用伺服器領域——在業界領先的應用伺服器 (Tomcat) 中佔據主導地位，並構建了下一代模組化應用伺服器 SpringSource dm Server。這解釋了為什麼 SpringSource tc Server 和 SpringSource AMS (應用管理套件) 為部署到資料中心的應用程式提供了強大的管理能力。

構建/執行/管理生命週期是我們看待世界的中心。在接下來的幾周和幾個月裡，您將看到關於產品和構建計劃的重大公告，以加強我們在整個生命週期中的發展。您將看到我們為了實現這一目標而拓展技術。

我堅信，透過解決這些問題，SpringSource 將成為一家主要的中介軟體供應商。然而，真正的贏家是你們。企業級 Java 可以（也需要）更具生產力。SpringSource 專注於這個目標，有能力實現它，而社群既支援我們的努力，也將從中受益匪淺。