你可能還記得 AMC Gremlin - 號稱史上最醜的車之一。 Gremlin 是在 70 年代生產的，但仍然有一些存在，例如我在去年於舊金山拍攝的這輛。

現今的企業級 Java 體驗讓我想起這段美國汽車的歷史。 Gremlin 是對石油危機的絕望回應。 AMC 需要一款「小型」汽車，所以他們拿了他們最小的汽車並將它切成兩半。 最終結果出乎意料地賣得很好，但明顯顯示出它的前部和後部是由不同的團隊生產並匆忙拼湊在一起的事實。 不用說，是日本和歐洲的製造商在向小型汽車轉變的過程中取得了勝利。

Java 中的 Gremlin

如今，企業級 Java 感覺很像 Gremlin，這是一個生產力方面的主要問題。 無論是在堆疊的上下層，還是在整個應用程式生命週期中，各個部分都是從不同來源拼湊起來的。 雖然大多數部分都很好，但其他部分對於典型的場景來說卻是過於誇大。 可悲的是，我們已經認為這是正常的，並且已經接受了生產力方面的後果。 例如，通常使用開放原始碼建置工具（Ant 或 Maven）來建置應用程式； 使用來自不同專案或供應商的 IDE，手動整合眾多外掛程式； 圍繞開放原始碼框架架構應用程式； 但部署到來自另一個供應商的應用程式伺服器——整合通常相對表面。

圖中的一些部分幾乎是給定的：像 Spring 和 Hibernate、基於 Eclipse 的工具套件，以及（越來越多的）Apache Tomcat。 但整體既依賴於開發人員為每個專案做出眾多選擇，也依賴於大量的內部膠合和支援——後者是另一個我們忽略或變得安於接受其成本後果的領域。

不必那樣

其他平台上的經驗表明了協同思考的好處。 Ruby on Rails 所實現的大部分生產力歸功於它提供了一個整合的體驗； 為開發人員做出了選擇，例如，建置是與應用程式框架齊頭並進地處理的。 Rails 從應用程式框架建立程式設計模型的前提開始，這一事實有助於為連貫的哲學提供基礎。

Microsoft 也提供了一個例子。 Microsoft 將從 Visual Studio 到 SQL Server（甚至還有 Azure，雲端）的所有內容都視為單一願景的一部分，並且，雖然並非所有組成部分都是理想的，但結果是比企業級 Java 提供的體驗更整合的體驗。

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

幸運的是，開放原始碼提供了以更開放的方式實現相同結果的機會。 雖然沒有任何單獨的開放原始碼專案解決完整的應用程式生命週期，但供應商可以透過大量利用開放原始碼來建構整合的體驗，從而最大限度地減少供應商鎖定。 基於開放原始碼進行建構也讓供應商能夠選擇每個領域中領先市場的解決方案，而不是從其內部零件箱中拼湊出產品（類似於 AMC）。

不僅僅是開放原始碼

但是，單獨的開放原始碼本身並不是解決方案。 開放原始碼專案通常擅長解決軟體堆疊或生命週期中的特定問題； 他們不太擅長（也不太感興趣）整合所有部分。 一個解決大局的現代解決方案，在整個應用程式生命週期中，將不可避免地依賴開放原始碼，但需要供應商的支持和支援。

令人驚訝的是，在 Java 領域，似乎沒有任何供應商挺身而出迎接挑戰，甚至很少有人嘗試過。 儘管 Sun 控制了 Java 規範，但它從來都不是一個強大的企業級 Java 供應商，並且似乎從未完全理解 Java 中的生產力問題。 （此外，生產力問題通常是由產品而不是規範解決的。 直到最近，並且可以說是太晚了，Sun 才開始在 Java 領域意識到這一點。） IBM 的確有涵蓋整個生命週期的解決方案，但在 IBM 的案例中，擁有協同的願景並不能彌補大多數組成部分糟糕的生產力特性。 任何以 Rational Application Developer 開頭並以 WebSphere 為核心的軟體生命週期解決方案不太可能提供現代的生產力體驗，或使 Java 能夠與競爭平台競爭。 儘管 Microsoft 有種種缺點，但它比任何傳統的企業級 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 將因解決這些問題而成為主要的 middleware 供應商。 但是，真正的贏家是你。 企業級 Java 可以（並且需要）更具生產力。 SpringSource 專注於這個目標，有能力交付，並且社群既支持我們的努力，也將從我們的努力中受益匪淺。