Java 20年：歷史與未來

　　作為最受歡迎的程式語言之一，Java已經走過了20個年頭。從已經落寞的諾基亞到現在火熱的電商系統，我們都能看到Java語言的身影。從1995年的第一個版本到現在的Java 1.8，我們甚至能從Java的版本迭代中看到不同時代程式語言關注的重點。經過了過去20年的發展，Java已經成為如今使用最為廣泛的企業級語言。為了慶祝Java的第20個生日，InfoQ為此採訪了Java技術專家彭晨陽（網路ID：板橋）。

　　InfoQ：您是哪一年開始接觸Java的？還記得當時『世界』是怎麼看這門語言的嗎？

板橋：我大概是2000年之前開始接觸Java，當時大家都認為Java慢，幾乎沒有幾個人看得上眼，那時使用Perl/C實現CGI比較快，PHP很方便。

　　InfoQ：能回憶下你的職業生涯中與Java相關的經歷嗎？

板橋：2000年之前使用Perl開發過一個類似西祠、西陸社群網站，隨著功能日益複雜，維護擴充比較麻煩，打算使用Java改造升級。但是Java比較複雜，當時有EJB等規範，因此誤用過EJB來做產品，其實EJB更適合做企業中可靠性要求比較高的專案。而對於社群專案來說，效能是關鍵，這個道理後來我從CAP定理中才得到答案，當然當時也沒有聽說過CAP理論，這段教訓是相當深刻的，EJB很難掌握，執行起來更慢，最後也以失敗告終。

之後研究學習了Jive開源Java論壇，對其設計模式與快取兩個優點進行了綜合學習與應用。有一段時間參與過手機遊戲的開發，那時客戶端是J2ME，但是遊戲邏輯不載入在客戶端，而是將客戶端只作為介面展現，類似今天的瀏覽器+Angular.js這樣富客戶端。當然，這個系統對網路要求比較高，但是當時無線網路3G還沒有推出，後來放棄了，從該專案中我意識到高效能的大型併發系統使用Tomcat這樣的普通Web伺服器已經無法承擔，於是對非同步訊息JMS等技術產生了興趣。

之後，陸陸續續參與過一些專案的諮詢和設計，大部分都比較普通，無非是CRUD增刪改查。於是萌生了做一個快速開發框架，在不丟失多層架構的基礎上能有Delphi等二層架構的開發效率，這大概是JDON框架的原型。當然，該框架後來從快速開發為首要目標轉移到靈活性為首要目標。

做了不少專案後，需要尋求理論指導，原來的資料庫+Java路數已經不能包打天下，後來逐步開始引入DDD領域驅動設計CQRS和EventSourcing。

　　InfoQ：很多人都在唱衰Java，您能結合Java的發展現狀和趨勢談談Java的前景嗎？

板橋：Java發展到今天已經20年了，作為一個程式語言確實不簡單，想當初人人受懷疑的慢語言到今天通用的健壯語言，真是大智若愚啊。Java代表的物件導向思想確實給工程領域帶來了革命性的變化，當然思想是不斷進化發展的，如今人們開始看好函數語言程式設計語（FP）。儘管Java 8也加入了函式語言的特點，但是OOP和FP兩者到底是不同的程式設計正規化，不過掌握FP有一定門檻，這也是造成很多人觀望的一個原因。

Java在資料流處理方面還是很有競爭力的，而大資料實時流處理系統是Java的新領域，在這個領域有Apache Kafka、Apache Samza、Apache Storm、Apache Spark的Streaming模組和最新的Apache Flink。Spark是基於JVM的函式語言Scala編寫，其餘都是Java編寫。

　　InfoQ：JVM的普及促使相關周邊語言不斷湧現，你怎麼看這些JVM語言？

板橋：以Scala為代表的JVM語言發展迅速，Scala語言特性是首先區分不變性和可變性，當初使用EJB時首先要區分是無狀態和有狀態，這說明思路是一脈相承的。可變性的狀態是造成副作用和各種Bug的罪魁禍首，可能我們如果只是把可變狀態使用資料庫實現時沒有注意到這種問題。其實這個問題遍佈在應用的每個角落，特別是使用類和物件這個OOP概念實現時最容易發生。一個類或物件包括欄位和方法，如果這個欄位值是可變的（可變狀態），我們使用這個物件時如果不開啟它的類程式碼是無法得知它有可變狀態的，那麼就會導致各種副作用發生。

而函式程式設計由於函式方法是第一公民，沒有什麼東西擋在它的前面，沒有類或物件包裹著它們，因此，它們無法私藏可變狀態欄位，能夠確保應用系統每行程式碼都是基於不可變的基礎之上。

如果說Scala之類JVM的函式語言適合不斷新增功能函式的應用場景，那麼Java之類的OOP語言適合不斷增加實體物體的應用場景。前者好動，後者好靜。

　　InfoQ：Java是如何擁抱雲時代的？

板橋：Java在雲時代面臨以Go語言為主的容器（Docker等技術）生態圈的挑戰。其實JVM也是一種容器，但是這種容器特性正在被Linux學習與趕超，那麼，JVM的定位就可能比較尷尬。

Docker之類容器可以在本地筆記本或電腦上執行，然後同樣可以部署到雲上執行。當在雲上執行時，Kubernetes能夠以一種可控的方式升級容器從而實現執行管理一批容器，如同一個大型船隊或艦隊一樣，你可以控制它們的流量訪問量，可以指定多少個容器來擴充套件支撐一個服務的執行，隨著訪問量提升，你通過增加容器數量能夠整個系統的負載能力。

當然，Java的大型分散式系統越來越多，Java在雲端計算與分散式系統中還是扮演主要角色，形成一個大型的生態圈。當我們站在泰山之上，一覽眾山小，當你在全球擁有多個資料中心時，語言已經變得不那麼重要了，關鍵是架構設計。

　　InfoQ：Go語言這兩年比較火熱，你怎麼看這門語言？與Java相比，他有哪些優劣？

板橋：Go語言相對Java主要優點是其併發元件模型，Java的併發比較低階，無非是多執行緒與鎖，想搞清楚Java中各種鎖的用途，包括資料集合Collection的執行緒安全性與效能差異對比，需要花費大量時間與精力，包括使用經驗。而Go語言使用了Channel/CEP這樣的元件簡單封裝了多執行緒與鎖，將以前JMS的Queue佇列模型架構引入到了語言之中，兩個物件之間互動只要通過Channel通道就可以。這種模型保證了併發性，有簡化了程式設計模型，無疑受到很多人的歡迎。

Go語言當前也受到更加強勁的Rust語言挑戰，如果說，Go語言的Channel是一種有形的設計，那麼，Rust語言的併發模型達到無形的設計，只要你編寫好函式方法，安全性與併發性就無形中得到了解決，不用專門去思考併發，有意識地去使用併發元件模型程式設計。

　　InfoQ：現在的開發語言特別多，Java、Go、PHP、Rust、Python等，你認為未來語言的發展趨勢是怎麼樣的？

板橋：現在的開發語言如雨後春筍，主要原因是CPU進入多核併發時代，以及大型架構進入分散式系統，如何使用一種語言從微觀的CPU多核之間併發到數萬臺伺服器之間的分散式計算處理，這種大一統的願景促使人們在不斷探索。

在Java中，我們可以通過框架來實現這點，以我前幾年研發Jdon框架為例，雖然能夠勉強實現併發與分散式，但是這種實現需要很強的知識背景，不利於初學者上手。而要達到普及這個目標，必須從語言入手，讓語言初學者在學習掌握語言以後，無形中就會實現了併發與分散式。

Go語言在這方面比較突出，其併發模型以讀寫操作為基礎。請注意，Java等語言併發模型沒有這麼高，它們是以執行緒為基礎，再應用到讀寫場景中，而我們現實中必須以讀寫為基礎，再應用到具體業務場景中，這裡面高低層次：執行緒–>讀寫操作–>業務應用，無疑越靠近業務應用的語言越能簡化我們的開發，而分散式系統也是基於讀寫操作，著名的CAP定理也隱含了以讀寫操作為基礎的語境。

　　受訪嘉賓介紹

　　彭晨陽，Jdon.com創辦者和版主。軟體開發設計諮詢從業20年，10餘年Java開發經驗，擁有ERP、大型遊戲、互動電視三網合一等架構經驗。獨立諮詢顧問，個人擅長複雜系統的軟體架構和領域建模。流行新技術思想的傳道者，主持解道網站跟蹤國際最新軟體架構思想和設計技術。首個國內Java開源框架專案Jdon框架的設計者。