1、JAVA會被什麼代替？這個問題有點無聊，10年前有有人這樣問，當時是因為SUN跟Microsoft 扯皮那點事，很多人擔心JAVA會被微軟幹掉，微軟想壟斷市場，3年前有人這樣問，因為培訓機構多了，JAVA開發人員多了氾濫了，怕自己沒有就業機會了，怕市場飽和了。2年前有人這樣問，像物聯網這種炒作了多年的技術也開始火了，人工智慧火了，在人工智慧時代擔心JAVA會被PYTHON這樣的語言幹掉，1年前人還有這樣的問，區塊鏈火了，怕不用JAVA都去使用C++了。

2、其實在我看來，各種語言有各種語言的優勢和特點，像所謂的大資料、雲計算、區塊鏈、爬蟲、資料分析、資料處理、資料建模、深度學習、機器學習、移動開發、桌面軟體開發、動態WEB開發...你告訴我有JAVA不能實現的嗎？都可以，只是某些領域它不擅長罷了。

3、我堅信，像JAVA這樣龐大的生態系統，不e79fa5e98193e4b893e5b19e31333365653762會輕易被任何一門語言取代，JAVA在中大型專案開發中，有著不可取代的地位。就算有一天JAVA真的被某種語言取代了，JAVA開發人員失業了，企業倒閉了，專案癱瘓了，反正又不是隻有你一個。再說只有它PYTHON開發者本人或技術團隊才會想到對人工智慧這樣的領域做出決策，難道它JAVA開發者本人就是傻子？ORACLE公司是傻子？ORACLE團隊是傻子？人工智慧時代，不發展了？區塊鏈不做了？

4、我認為技術和人才是同時更新的，現在的很多JAVA開發者被淘汰的原因，其實就是跟不上技術的發展，技術不行，還是隻會SSH、SSM，沒有框架啥不都會寫，沒有開發工具和框架，就用個記事本，我估計做箇中小型專案都是問題。分析一個某類庫中提供的方法實現原理一問十不知。你告訴這樣的所謂的人才公司要嗎？平時不要對自己太好了，小心招報應。

對於最近有關 Java 即將退出歷史舞臺的傳言，您可能想知道在這個時候放棄使用 Java 平臺並轉而使用更新的技術是否時機成熟？在作出您的判斷之前，請先回顧並檢視一下 Java 生態系統以及它的競爭者，看看這些傳聞是否站得住腳。換而言之，瞭解整個 Java 世界目前的現狀，並客觀公正地評判這個平臺。

在學生時代，我們可能會想起 Thomas Malthus 所做的預言，他認為人類賴以生存並繼而形成人類文明的農業體系，可能無法再承受人口數量的不斷攀升，另一方面，這種情況將不可避免地造成嚴重的後果，通常會引起巨大的災難或其他自然災害。他這樣寫道：若對人口數量不加限制，將呈幾何比例增長。而人們賴以生存的物質則以算數比例增長。與後者相比較，如果稍微瞭解一下這些數字，就會意識到人口增長是多麼驚人。這意味著，針對生存物質的匱乏，需要對人口增長進行嚴格而持久的控制。物質匱乏終究會發生在某些地方，並且必定會嚴重影響到大部分人類。

Thomas Malthus 在 1798 年發表了 “人口論”。從那時開始，我們一直在等待著驗證有關人口增長的 “Malthusian 檢驗”。

程式設計人員，特別是使用 Java 平臺和語言的人員，可能已經注意到，隨著使用難度不斷增加，人們的種種預測和統計暗示著他們所選擇的平臺即將沒落。而大量候補接任者躍躍欲試：人們提名 .NET、Ruby 甚至是 Python 作為 “下一代重要技術”。

這兩種 “Malthusian 學說” 之間存在著驚人的相似之處。

Malthus 認為，由於食物對人類的生存非常重要，而地球的產出有限，並且繁殖所需的生物體系是不會改變的，我們終將達到一個極限，那時地球將無法承受人口負擔。換句話說，如果繼續以現在這樣的方式生存，將註定滅亡的結局。那麼在 1798，很難推翻 Malthus 的學說。

同樣，在過去十八個月中，Java 社群出現了一種新趨勢：即預測 Java 平臺的消亡日期。從一些低階的新聞雜誌將其稱為 90 年代的技術，到誇大其辭的技術演講者宣傳它的現狀，再到各種書籍宣稱我們正在 “超越” Java 時代，不難發現一點：透過合理的暗示、程式碼演示、邏輯或統計性說明，Java 正在走向沒落。

Malthus 錯過了工業革命，而後者引發了翻天覆地的變化。在 Malthus 一生中，他見證了人類農業生產力的巨大飛躍，這要得益於蒸汽機和軋棉機這些發明。這些裝置為他的學說提供了重要的 “缺失的聯絡”，它們使糧食產量成倍增長，從而使農業系統能夠戰勝製造了大量人口的 “兩性激情”。隨後，人口控制方面的技術創新對降低人口增長起到了相同的作用，減輕了人口負擔，從而造成了很多西方國家出現人口負 增長，因此情況與 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 的其他開源“淨室”實現（Apache Harmony 和 Soy Latte 只是其中之二），即使 Sun 公司徹底從地球上消失，包括 IBM?、Apache、BEA 和 Oracle 在內的其他實體也能繼續提供 JVM、庫和工具，來支援整體生態系統。

Java 總有一天會消亡？絕對會的，但是我堅信 Java 的壽命會超過今天的程式設計師所使用的大部分語言，正如 COBOL 做到的那樣。它甚至能比剛剛走出大學校園的第二代 Java 程式設計師走的更長。

“恐龍”，確實如此。