你可能還記得AMC Gremlin——它是最醜陋汽車的有力競爭者。Gremlin是在70年代生產的，但仍然有一些，就像我去年在舊金山拍到的這輛。

如今的企業 Java 體驗讓我想起了美國汽車工業的這段遺產。Gremlin 是對石油危機的絕望回應。AMC 需要一款“緊湊型”汽車，於是他們拿出了最小的車型，然後將其一分為二。最終的產品銷量出奇地好，但卻暴露了其前後部分由不同團隊生產並倉促拼湊而成的明顯跡象。毋庸置疑，在轉向小型汽車的潮流中獲勝的是日本和歐洲製造商。

Java 中的 Gremlin

如今，企業 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 需要一個新的旗手，而這個旗手將不是任何一家現有公司。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 來幫助加速企業 Java 與 Spring 的開發。

這解釋了為什麼我們已經進入了其他領域，例如應用程式伺服器領域——在行業領先的應用程式伺服器（Tomcat）中佔據領先地位，並構建了下一代模組化應用程式伺服器 SpringSource dm Server。這解釋了為什麼 SpringSource tc Server 和 SpringSource AMS （Application Management Suite）為部署到資料中心的應用程式提供了強大的管理功能。

構建/執行/管理生命週期是我們看待世界的中心。在接下來的幾周和幾個月裡，您將看到關於產品和構建計劃的重大公告，以加強我們在整個生命週期中的戰略。您將看到我們擴充套件我們的技術以追求這一目標。

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