來自一年前的預測：Java平臺與死亡相去甚遠
在學生時代，我們可能會想起 Thomas Malthus 所做的預言，他認為人類賴以生存并繼而形成人類文明的農業體系，可能無法再承受人口數量的不斷攀升，另一方面，這種情況將不可避免地造成嚴重的后果，通常會引起巨大的災難或其他自然災害。他這樣寫道：若對人口數量不加限制，將呈幾何級數增長。而人們賴以生存的物質則以代數級數增長。與后者相比較，如果稍微了解一下這些數字，就會意識到人口增長是多么驚人。這意味著，針對生存物質的匱乏，需要對人口增長進行嚴格而持久的控制。物質匱乏終究會發生在某些地方，并且必定會嚴重影響到大部分人類。
Thomas Malthus 在 1798 年發表了 “人口論”。從那時開始，我們一直在等待著驗證有關人口增長的 “Malthusian 檢驗”。
編程人員，特別是使用 Java 平臺和語言的人員，可能已經注意到，隨著使用難度不斷增加，人們的種種預測和統計暗示著他們所選擇的平臺即將沒落。而大量候補接任者躍躍欲試：人們提名 .NET、Ruby 甚至是 Python 作為 “下一代重要技術”。
這兩種 “Malthusian 學說” 之間存在著驚人的相似之處。
Malthus 認為，由于食物對人類的生存非常重要，而地球的產出有限，并且繁殖所需的生物體系是不會改變的，我們終將達到一個極限，那時地球將無法承受人口負擔。換句話說，如果繼續以現在這樣的方式生存，將注定滅亡的結局。那么在 1798，很難推翻 Malthus 的學說。
同樣，在過去十八個月中，Java 社區出現了一種新趨勢：即預測 Java平臺的消亡日期。從一些低級的新聞雜志將其稱為 90 年代的技術，到夸大其辭的技術演講者宣傳它的現狀，再到各種書籍宣稱我們正在 “超越” Java 時代，不難發現一點：通過合理的暗示、代碼演示、邏輯或統計性說明，Java 正在走向沒落。
Malthus 忽略的是那個時候正興起的工業革命。在 Malthus 一生中，他能夠目睹到人類農業生產力的巨大飛躍，這要感謝蒸汽機和軋棉機這些發明。這些發明為他的學說提供了必然的“缺少的一環（missing link）”，它們使糧食產量成倍增長，從而使農業系統能夠擬制由“兩性激情”制造的沉重的人口負擔 。隨后，人口控制方面的技術創新對降低人口增長起到了相同的作用，減輕了人口負擔，從而造成了很多西方國家出現人口負 增長，因此情況與 Malthus 的相當合理的邏輯完全相悖。而所有這一切在 Malthus 撰寫其論文時是無法預見的，使人類能夠超過他所預測的農業系統的承受極限而繼續存活，并且避免了由此而來的一系列災難。
而技術批評家所忽略的則是 Java 虛擬機的替代語言的興起引發了巨大的變化。不過不要輕易相信我的一家之言，讓我們逐一查看支持這種說法的論證，看看它們是否站得住腳。
Malthusian 式的 Java 預測
一些人僅僅引用了一些統計性描述，說明 Java 不再是程序員中最重視的語言，就簡單的判定 Java 已經在走下坡路。其他人指出 Java 缺乏其替代環境所提供的某些特殊特性，這些特性被標榜為用戶及其應用程序的 “需求”。還有一些人發表（毫無事實依據）諸如 “大企業不會再使用 Java” 等言論，從而明確地暗示，如果大企業不使用 Java，那必定是因為這種技術不值得使用。
Java 語言，從更大的程度來講，Java 平臺及其生態系統，很早以前就超過了 Simon Peyton-Jones 所謂的 “生存閾值（The Threshold of Immortality）”，就像 C++、C、COBOL 和其他語言所經歷的一樣。這些工具幾乎可以永遠存在下去，這是因為它們將繼續提供有用的功能，或者是因為重寫代碼的嘗試可能要比繼續按原樣使用和維護系統付出更多的代價（有關特定語言或系統究竟屬于這兩個原因的哪一種，存在很多的爭議，而這對于本文的目的則無關緊要）。
另一個論據讓所有聰明人都放棄 Java 而轉向平臺 X 或語言 Y。在 2005 年的一篇 BusinessWeek 文章 “Java? It's So Nineties”中，引用了很久以前就倒閉的應用服務器公司 NetDynamics 的前 CTO Peter Yared 的話，“Java 像恐龍一樣古老”。可是，還未來得及搞清楚利益沖突和推理邏輯，這篇文章就寫到 Yared 所有的公司正在嘗試在 LAMP（Linux?/Apache/MySQL/P-language）棧之上重新創建應用服務器體驗。
（這樣做可能有些無禮，但我還是要指出 Ruby 的構想實際上早于 Java，同樣還包括 Perl 和 Python，更不要說 Linux、Apache 和 MySQL……這里我就不便再多做解釋了）。
引用我喜歡的一部電影，“生活是痛苦的，殿下。持不同觀點的人一定有所企圖”。或者，為了更恰當地解釋這個主題，可以這樣說：“過渡到一個新的平臺是痛苦的，CTO 先生。持不同觀點的人一定有所企圖”。也許并不令人驚訝，對于一些已經重新定位到其他技術領域的 Java 專家來說，情況確實如此。
來看看另一個論據，它說 “Java 的***語言的位置已經不保，因此它的衰退必定非常悲慘，因此***避開這場災難”。這種論據所依據的是一個最基本的前提，即如果 Java 不再是世界上最暢銷的技術，則不值得再提供該語言的支持。而這種說法若經過邏輯推理，則根本毫無道理。
統計信息很久以來一直被認為是不可靠的（如果使用不當的話），正如 Benjamin Disraeli 的巧妙解釋，他說：“世界上有三種謊言：謊言，詛咒和統計”。統計信息可以用來論證最靠不住腳的論據，只需要根據論據仔細挑選所需的統計信息。注意 BusinessWeek 一文中使用的引用：“調查……顯示 Java 的使用逐漸沒落，而 LAMP 和 Microsoft 的 .NET 技術勢頭強勁”。喔，聽上去情況不妙。但是，請繼續讀下去，“根據 Evans 的秋季調查顯示，在北美使用 Java 作為其***編程語言的開發人員的比例已下降到 47.9%，而 2002 年秋為 51.4%”。因此，在過去六年中，在使用 Java 作為其*** 編程語言的開發人員中，使用率下降了 3.5 個百分點。
請注意，這里使用了 “***” 編程語言一詞，這意味著開發人員自己需要區別什么是他們的 “***” 語言。考慮到大量的 XML 配置，使用 Spring/Hibernate/JSP Java 棧的開發人員可能可以很好地判斷出 Java 不再是他們的***語言。
注意過去六年中 Java 平臺之上興起的動態語言（Jython、JRuby、Groovy 甚至是 JavaFX），根據我和我的同事（“No Fluff Just Stuff” 的演講者）在 NFJS 活動的非正式投票中獲得的應用數字，這些動態語言可以很輕松地解釋這三個百分點的下降。
考慮同樣摘取自同一篇文章的引用：“在另一份調查中，今天秋季，PHP 在北美的采用已經上升到 36.1%，而 2002 年同期為 26%。其增長速率幾乎和歐洲和亞洲一樣快”。考慮到這是一個不同的調查系列，它只是為了顯示 PHP 的增長，而不是 Java 市場的萎縮。祝賀 PHP，但是任何研究過企業環境的開發人員都可以證明，生產軟件部署并不像這篇文章的作者力圖暗示的那樣是一個零和（zero-sum）游戲。大型 IT 環境通常由種類繁多的工具、平臺、語言和產品組成。事實上，我們幾乎可以在這里實現 整合，特別是那些大型機組件。
談到主機，事實上，COBOL 在幾十年前就不再是最重要的語言了，但是，它現在仍然繼續用于現金支付、轉移存款、支付信用卡等業務并運行主要的金融網絡，盡管很多行業權威早已經宣布了它的 “死亡”。對于本應在墳墓里腐爛的技術，這實在是不錯；這使我想起 Mark Twain，當他看到家鄉報紙上他的訃告時說：“先生們，關于我死亡的報道被嚴重夸大了。”
然而，撇開統計數字的問題不談，第二個問題更嚴重：為什么僅僅因為所選的工具不是***的就棄而不用？Java 占據軟件開發的首要地位近十年，僅僅由于它 “下降” 到第二位，游戲就結束了？甚至認為僅僅因為人們的惰性就會阻止 Java 重新恢復首要語言的位置，事實是，10 個程序員里面有 4 個會繼續使用這種語言，這將保證 Java 在未來幾十年里仍然保持活躍的生命力。更荒謬的說法是，Java 的增長將面臨急剎車，并且再也不會出現 Java 部署，然而，Java 目前在整個行業內得到了廣泛的部署，這可以保證 Java 繼續出現相當長的時間。
盡管 COBOL 被宣布已經死亡，但是要求使用它的人每年達到 6 至 7 位數。
檢查證據
然而指出一個論點的缺點并不能證明另一個觀點，對于本文也是一樣的。相反地，我們應該用批評的眼光看待 Java 語言和平臺，而其強項和劣勢經受住了嚴格的分析。Java 之所以長壽在于它能滿足未來十年的需求，而不是由任何作者或批評家來決定它的生死。
***，我們考慮一下構成 Java平臺的那些組件：
Java 編程語言。坦率地講，這是平臺中最能體現其長壽的部分，特別是與一些諸如 C#、Groovy、(j)Ruby 或 Scala 等更 “現代的” 語言比較時。近來涌現出大量關于改善該語言的建議，諸如為該語言添加閉包等***競爭力的提議，證明了程序員非常渴望 Java 能夠具備其他語言的一些特性。然而，Java 5 中***語言增強功能所帶來的聯合成功應該成為所有新的重大語言變更的“注意剎車”的提示。某些增強，比如 for 循環或注釋，得到（相對）普遍的支持。然而其他一些增強，比如泛型，則受到（相對）普遍的嘲笑和批評。事實是沒有任何一種語言功能能得到它本應幫助的開發人員社區的普遍接受，這個事實告訴我們：為一個已存在十年多的語言添加新的語言特性是很棘手的事情，如果完成，也很可能會導致語言自身的崩潰。在 Java 平臺的地圖中，這個區域標注著“老水手”的警告：“此處有怪物！”
非 Java JVM 編程語言。在 Java 止步不前的地方，其他語言提供改進和增強的解決方法。Groovy 圍繞 Java 對象提供了一個動態、客觀的腳本解決方案。(j)Ruby 在 JVM 之上提供 Ruby 實現，為 Java 程序員開辟了 Rails 和 ActiveRecordoffers 的世界。Scala 和 Jaskell 給 JVM 引入了函數編程概念，為所出現的并發性問題提供可行的解決方案。諸如此類。由于所有這些語言要么編譯成字節碼，要么通過 javax.script API 作為解釋語言在 JVM 上運行，因此 Java 生態系統的所有財富都是可以利用的——而這是 Ruby 開發人員無法做出同等聲明的一個方面。在 Java 平臺的地圖中，這個區域被標注為“機遇之國”。
Java 虛擬機。 幸運的是，Java 語言已經做出了重大修訂和根本性的變化，而 JVM 作為 Java 平臺的底層基礎，變化并不多。近來，在博客世界中，許多人建議使 JVM 對動態語言更友好，這使 Sun 公司的一名工程師（John Rose）提供了 JVM 的修訂版，最初稱為多語言虛擬機（ Multi-language virtual machine，MLVM）, 現改名為 Da Vinci Machine（因為緊密地包裝在代碼中）。此處的關鍵在于被提議的 JVM 更改要避免任何有可能使 Sun 公司在 JVM 優化上的龐大投資作廢的事件。那些提出建議的人在設計細節時一直將這一點牢記于心。
Java Standard Edition 庫。 Java Standard Edition 附帶了巨大的函數集，數量級比 C++ 標準庫更大，甚至許多因素比它前身 Java 1.0 都大，并且這還沒有考慮 Enterprise Edition 庫（接下來討論）。表面上，這看起來像 Java 開發人員的自然優勢，但仔細考慮就會發現一些細微的問題。對初學者而言，庫的龐大意味著許多 Java 開發人員認識不到他們在寫一些實際已經存在的代碼，這些代碼收藏在一個在此之前未知的包中。根據存在時間的不同，庫本身有時也會遇到 API 設計時間的煩惱，其中有許多 都源于 90 年代中期，那個時候開發人員設計類和庫的方式與 2008 年的設計方法截然不同。一部分開發人員也深受抽象過多之苦，正如創建對象構建者的工廠所例證的一樣，這些對象構建者創建的接口實例不一定能實現開發人員感興趣的方法。然而，雖然 JSE 庫有缺陷，但從整體來說 JSE 依然有優勢，尤其是當它與像 Groovy 提供給 JDK 的擴展（稱為 GDK）這樣的語言支持增強結合時。
Java Enterprise Edition 庫。 沒有任何技術能夠比 EJB 對其社區產生更大的沖擊，并且幸運的是，Java 社區看到了輕量級替代方案的興起，Spring 和 Hibernate 提供了***的例證，對這些場景來說，輕量級替代方案是理想選擇。然而，如果暫時不考慮 EJB，Java EE 庫就是非常成功的 — servlets 和 servlet 容器為遍及 Internet 和企業內部網的大量 Web 應用程序提供動力，JMS 提供對多種面向消息中間件系統的訪問，JEE 領域中其他不太知名的參與者（如 JNDI） 毫無怨言地執行自己相應的任務。JEE 庫很有可能受益于 API 重新設計，JSE 庫就是這樣，總體來說 JEE 庫將滿足 Java 程序員的需要。***的問題往往在于認識何時首先需要 JEE 庫。我們將在另一篇文章中討論相關內容。
Java-API-for-XML (JAX) 庫。 盡管名義上是 JEE 庫的一部分，但 JAX API 的數量和規模都在以與 JEE 其他部分不相稱的速率增長，值得脫離 JEE 的上下文來考慮 JAX API。在近十年，盡管對 XML 支持的需求是巨大并且普遍的，但目前已經有所緩解，尤其是 Web services (WS-*) 周邊領域和規范陣營（這些規范允許與其他技術之間實現普遍、輕松的互操作，包括 .NET）。在這里，Java 無疑需要某種類型的修訂，由于 SAX、DOM 和 StAX API 經常需要更多的代碼來完成重要任務，尤其是和具有更靈活的 XML 支持的語言相比時，比如 E4X、Ruby 或 Scala。此處，以 XML 為中心的思想有了明顯的改變，從早期的 WS-* 實現中“不接觸 XML”到基于 RESTful 方法的“我希望直接接觸 XML 并將其定址為形式良好、有意義的 URI”，這種方法也強調了 JAX 領域內重構的必要性。在 Java 世界的地圖中，這個區域被標注為“（應該）棄用的”。
客戶端 Java。Sun 公司最近修訂的“Java客戶端”系統的測試版有個相當糟糕的名字 “Java SE 6 Update 10 Beta”，它提供了增強的客戶端特性，包括新的 Swing 外觀，稱為 Nimbus。遺憾的是，在客戶端度量 Java 的使用一直都存在問題，主要是因為專門用于度量的 applet 在 Internet 上已經使用了很長一段時間，還因為眾多對 Web 托管應用程序的設計和架構關注點都以 HTML 的生成為中心，而不是生成現在所說的“富客戶端”應用程序。隨著采用速率的提高，Java 要經過漫長的旅程，追趕它在這個領域中的主要競爭對手，Flash 和微軟在該領域新引入的技術 Silverlight 使情況變得更加復雜。Java 可能也會徹底失去陣地，這并不代表著這種平臺的“消亡”，但會使問題惡化，當業內學者和商業雜志將其稱為“Java 技術弱點的明顯例證”時，一定要鼓舞自己！
服務器端 Java。 這實在不容爭議：Java 毫無疑問是服務器領域內既定的參與者，特別是在查看非 Windows? 后端系統環境的選項時。LAMP 系列產品可能提供一個前端或垂直豎井的替代方案，包括 Ruby on Rails 也是一樣，但觀察重要的服務器計算基礎設施時，Java 系列產品將占據顯著的位置。事實上，正是這種領先地位促使微軟***積極地尋求 WS-* 規范，以使 .NET 代碼至少能調用和配合既定的 Java 基礎設施。微軟最近認可了使互操作性向更正式的水平發展，他們在劍橋大學設立的“Interoperability Lab”也體現了這一點。
生態系統。 沒有其他的平臺擁有像 Java 平臺一樣如此豐富多樣的生態系統，然而這經常會給 Java 開發人員帶來一些麻煩（“我該使用哪種 Web 框架？”），事實上，很多 Java 生態系統都滲入其他環境，尤其是.NET。考慮 .NET 近來在微軟內外獲得的進步：ObjectBuilder（依賴性注入框架）、ASP MVC（基于 MVC 的 Web 框架）、NHibernate（Hibernate 的一部分）、NAnt 和 MSBuild（在句法或概念上與 Ant 相似的基于 XML 的構建系統）甚至 Silverlight 本身（在瀏覽器內部托管 CLR，允許執行更豐富的客戶端）。在許多方面，.NET 生態系統為 Java 社區做了將近五年的后盾，因為 .NET 開發人員發現了與 Java 開發人員在五年前遭遇的相同痛點。而 Java 仍然堅持向 .NET 社區學習（比如統一通信 API 的有用性或顯式輕量級工作流引擎的強大力量）。這只用來說明這些環境都正在互相學習這一事實，而且也表明，.NET 并沒有使 Java 成為不必要的能力。
毫無疑問，Java 開發人員可以將他們自己的條目添加到這個列表中，證明這個論點：在 Java 平臺中留有太多的優良的東西被認為“死亡了”或“將要死亡”或者甚至在“崩潰的邊緣”。
王者終將歸來
最簡單的事實是：Java、平臺、生態系統、環境和開發社區與死亡相去甚遠，至少和目前正在使用的其他語言或平臺距離一樣遠。即使是最嚴格的統計事實篩選也不能否認 Java 的領先地位。
此外，即使 Sun Microsystems 公司倒閉，平臺也不會消亡。全世界的 Java 開發人員，聯合起來！不要懼怕束縛的鐵鏈：最終您將看到，這些鐵鏈其實并不存在。多虧 Java 平臺的開源，它現在被稱為 OpenJDK，更不要說 Java 的其他開源“凈室（clean room）”實現（Apache Harmony 和 Soy Latte 只是其中之二），即使 Sun 公司徹底從地球上消失，包括 IBM、Apache、BEA 和 Oracle 在內的其他實體也能繼續提供 JVM、庫和工具，來支持整體生態系統。
Java 總有一天會消亡？絕對會的，但是我堅信 Java 的壽命會超過今天的程序員所使用的大部分語言，正如 COBOL 做到的那樣。它甚至能比剛剛走出大學校園的第二代 Java 程序員走的更長。
“恐龍”，確實如此。
本文來自IBMDW中國：《COBOL 式死亡》。
【相關閱讀】
