Ben Evans是jClarity的共同創辦人。其公司致力於開發可以為開發和維運團隊提供幫助的性能工具和服務。他是LJC（倫敦Java使用者小組）的組織者之一，也是JCP（Java社群過程）執行委員會的成員之一，幫助定義Java生態系統中的一些標準。他也是“Java Champion”榮譽得主。他曾與人合著了《Java程式設計師修煉之道》（The Well-Grounded Java Developer）和《Java權威技術手冊（第6版）》（Java in a Nutshell）。他曾就Java平台、效能、並發和相關主題發表過多次演講。
問：《Java權威技術手冊》（Java in a Nutshell）是一部經典，它的上一版（第5版）長達1200頁，而在十年後即將在中國出版的第6版卻只有400頁，這兩版到底有什麼樣的變化？對Java來說，這十年意味著什麼？
第1版《Java權威技術手冊》是在Java剛剛變得流行之後很快出版的，那個時候人們對於Java充滿了想像。在接下來的五個版本裡，這本書越變越大，內容不斷延續。所以每一本的重點都有些著眼於歷史，因為幾個版本之間有著演進的關係。這是由幾個因素造成的結果，有一部分原因純粹是因為這樣比較好寫，你只要知道這個版本和上一個版本相比增減了什麼就可以了。但更重要的是，在早些時候，在大部分企業中，Java的生命週期很長，所以你經常可以看到很老版本的Java。所以理解不同版本之間的差異就變得很重要。所以當你在某家公司某個Java版本上工作時，如果你知道版本是哪個，你也就知道了能做什麼不能做什麼，以及這個版本與其他版本相比有什麼樣的改變。
這就是當我開始寫新一版時，第一個想改變的事情。因為現在最新版的Java 8（說到這裡，容易讓人有些混淆，《Java權威技術手冊》的第6版講的是Java的第8版）的生命週期比以前短了很多。當然，這要取決於具體領域，但是在了解了普遍的使用情況後，你會發現使用舊版的（例如Java 6）只是極少數的人。當然仍然有一些瘋狂的人仍然在使用6以前的版本，大部分的用戶使用的是版本7。現在，版本8正在以很快的速度佔領市場，僅僅在半年時間，有15%到20%的用戶已經在使用Java 8了。所以新版《Java權威技術手冊》的焦點比以往更加開放，我們開始關注Java以外的世界，也會討論現在和未來。
第二件重要的改變是長度，正如你所說，第5版長達1200頁，而第六版只有它的三分之一，當我開始著手整理上一版的時候，我做的第一件事就是去掉了三分之二的內容。如果你看過第五版，你就知道除了討論Java的主要內容之外，這本書的第二部分是關於索引的。當然這也是歷史原因造成的，當Java剛出來的時候，網路的使用還不是很普遍，所以書自帶一份索引是很合理的事。但還有另外兩個原因，Java平台變得越來越大，在《Java權威技術手冊》的第一章我討論了Java版本進化，指出了Java平台的增長速度之快。要描述Java 5平台的基本知識就花了800頁，那還是Java 5的時候，如果用同樣的方法討論Java 8的話，這本書就要頂到天花板上了。可見這個方法不可行了，沒有人會願意拿著這樣一本書。另外一個原因（也許這兩件事是相關的）就是人們利用技術資訊的方式發生了改變，因特網如今無處不在，人們不願意攜帶厚重的書籍，所有的索引都可以在網上的PDF、網站等資源中找到。所以這時候還要在紙本書的後面加上厚重的索引就很不合理了。這就是《Java權威技術手冊》兩個版本之間的重大改變。
我嘗試的第三件事是捕捉Java的變化趨勢和規律。所以很多關於過去如何使用Java的內容都被去掉了，我加入了更多現代的使用方法，讀者們需要了解垃圾回收，內存分配，並發編程，我在這些方面講了很多。這裡面涉及了大量的工作，因為原來的版本都著力保存原來的內容。在第五版留下的三分之一內容中，大概只有25%-30%留到了第六版中，這些內容也都重新編輯整理過，而剩下的70%左右的內容則是全新的。
因為，我們想在Java 8投入使用的時候就把這本書弄出來，所以Java 8還沒出來的時候我們就動筆了，到了後來還出現了一些一開始沒有想到的工作（比如Java 8上隱藏的特性）。但這次我們的經驗更豐富了，所以希望能在2016年4月，Java 9出來的時候完成下一個版本。事實上我已經做好具體計劃了。
問：對於《Java程式設計師修煉之道》（The Well-Grounded Java Developer）你有下一步的計劃嗎？
《Java程式設計師修練之道》這個專案很好，寫作的過程也很愉快。但是在寫作《Java權威技術手冊》的過程中我消耗了大量精力，我認為我可能不會再寫這本書的第2版了。我和這本書的原出版商Manning談過了，但是最新的進展我並不了解，所以很有可能這本書不會再有第2版了。
問：一位Java大牛和一位普通Java程式設計師之間的區別是什麼？
我認為可以把程式設計師的層次看作一個金字塔，其中可以大致分成3個層次。在最底層的是很勤奮的程式設計師，但是他們可能對程式設計本身興趣不大，他們也能做好工作，但是他們下班之後就不會再想關於程式設計的事。這是很正常的現象，軟體業需要很多程式設計師，而這個需求仍在持續成長。中間層次的程式設計師，想再多做一些，他們閱讀科技新聞和網站上的消息，他們會跟進下一個版本的進展，他們關心自己的技能，這個層次的程式設計師很有趣。而最上層的程式設計師則是時時刻刻對技藝以及技術的本質著迷。當你到達了這個金字塔的最頂層時，你就會開始有回饋環，你可以從自身學習，對技藝的了解更深刻。但是我認為最困難的部分就是如何從第二層突破到最頂層。如果你對你所做工作以外的知識有一丁點興趣，你就要尋找屬於自己的那個點，這個點對於每個人都不一樣，一旦發現那個讓你著迷的領域，你就可以隨著好奇心的驅使深入學習下去。
關於開源軟體有一個說法，一個好的開源開發者必須找到自己的痛點，他們不得不去解決這個困擾他們的問題。這是大多數人對開源軟體感興趣的原因，也是許多人稱為Java開發者的原因。你找到了一個讓你感興趣的點，由於不明所以，你一直學習下去，這就是成長的秘密。
問：雖然Lambda加入了Java 8，但在開發者之間始終有關於Java語法過於冗長的抱怨。你認為這是很多開發者和團隊不願意使用Java的主要原因嗎？
我不這麼認為。 James Gosling有三句話可以解釋Java的語言設計，以及為什麼Java是現在這個樣子。第一句就是英文所說的「藍領」語言，藍領工人是從事第一線工作的人，而白領則代表了辦公室以及經理們的工作。 Java就是一種藍領語言，它的設計是為了讓工作中的程式設計師解決真正的問題。 Java是實用的語言，它解決的是真實世界中的業務。
James Gosling在2014年JavaOne大會上談到了Lambda以及Java的早期版本中沒有出現的一些設計，他說：如果我沒有找到完成一件事的正確方法，那我就什麼都不做。這句話表達了一種緩慢而保守的演進設計思想，要理解Java是什麼，就必須明白這一點。很多人覺得Java老了，程式語言需要改變，但是他們沒有搞清楚的是，真正改變的是他們自己。他們在能力上有了發展，他們想看得更遠更深，而語言反映出了這一點。並不是語言需要改變，而是提出這個觀點的程式設計師本身就改變了。 Java從過去到未來都是一種設計保守的語言。這也是Java的一大優勢。
當James解釋他設計Java的初衷時說：當我在設計的時候，我知道人們想要自動內存管理，人們想要強型式，但是這些功能會嚇跑藍領工人。比如說Smalltalk，這是一門很優秀的語言，但是它太先進了，它和現實中開發者們在建構應用時的思維脫離開來。所以Java繼承了其中的一些理念，並將其簡化，把這些理念放入一種語言和格式。這些事解釋了這門語言設計的基本動機。
所以你當然可以說Java是一種冗長的語言，但我認為額外的內容是為了方便閱讀。特別是當你還是一位初級或中級程式設計師的時候，那些看似多餘的文字能夠幫助你。人們永遠記得我們對於生產力的需求越來越高，但是程式碼仍然是寫出來的。所以我不認為Java冗長，雖然我們可以加入一些高級功能，但有些事永遠無法在一個語言中改變，這很遺憾。當然我們也會進步，但是就像我總說的一句話，人們總是太在意文法，而不是能用語言來實現什麼。
問：現在不少的大企業（Paypal等）從Java切換到Node.js，Java在企業中的地位受到威脅，Java和Node.js各自擅長的領域是什麼？
這個問題中有一個誤解，事實上並沒有出現大波公司棄用Java轉向Node.js的情況。 Paypal中啟用Node.js的部分規模很小，Paypal的大部分運行程式碼仍然是Java。 Node.js參與的只是一個試點項目，這是可以理解的，Node.js是一個有趣的環境，其中也有一些有趣的想法。 Node.js十分年輕，同時，它也有很多嚴重的問題，所以現在預測Node的未來發展還為時過早。所以雖然各種開發者網站上有很多支援Node的聲音，GitHub上有很多有趣的專案（例如用它寫Ardruino，玩硬體），但是在所有生產環境下的產品中，毫無疑問，Java擁有最多的程式碼行。企業在沒有充分理由的情況下不會捨棄工作軟體，雖然有很多使用Node.js的創業者，但是創業者們來得快，走得也快。
作為近年來有趣的產品之一Twitter，如果你觀察一下他們的發展你會發現他們最開始用的是Ruby on Rails。三、四年前，他們的網站開始出現一個非常可愛的卡通形象，失敗鯨。這是一件很尷尬的事，為了弄清楚到底發生了什麼，他們做了很多調查，在查看了Ruby的垃圾收集之後，他們發現自己無能為力。同時，他們的Java試點計畫獲得了成功，他們意識到Java能解決他們的擴展性問題。然後在接下來的18個月，他們使用了一些JRuby作為中轉站，然後將整個系統改寫成Java。最終的效果也很好，他們圍繞著Java引入了新的服務，新的架構。曾幾何時，Ruby被視為企業級軟體的未來，但現如今，Ruby只是眾多程式語言中的一種。現在應用最廣的三種語言是Java，JavaScript，以及C/C++，但是大部分的JavaScript程式碼都是在客戶端，如果把這三種語言去掉，其他語言的市佔率都非常小。
問：直到現在，Java應用的虛擬託管模型需要分配給整個x86虛擬機器用來託管一個單獨的JVM實例，相對來說實例上也託管了單獨的Java應用。這樣的方法效率很低，但是Java本機並不支援多租戶虛擬以及雲端運算配置。幸運的是，在社群裡可以找到一些為了解決雲端運算問題而產生的多租戶Java解決方案，你認為哪個方案足夠成熟可以應用到生產環境？
這裡麵包含了兩件事，把虛擬和雲端以及多租戶混在一起並不完全正確。比如說在QCon上海上有很多分享是關於docker的（docker是一個不依賴虛擬化的平台），其中一個精彩的分享來自於Chris Swan。他展示了將CPU記憶體從虛擬環境轉移到以Docker為基礎的環境所帶來的好處，雖然仍不夠完善，但是它已經為Java帶來了額外的優勢，只要在Docker上運行Java你就能感受到。我們應該把雲端和虛擬的關係梳理清楚。另外，還有很多其他你可以做的事，例如你可以建立多個JVM主機。
但是這個問題真正在問的是多租戶。關於這個問題，有一個產品在我心中是當之無愧的冠軍，那就是Waratek。 Waratek可以把一個單獨的非熱點JVM分開，並且在其中運行主機JVM，在JVM裡運行的是Java虛擬多租戶JVC，而JVC可以做到很輕量級。我認為Waratek是一個很成熟、可以投入使用的產品，德意志銀行剛剛宣布把自己的第一個工作JVM挪到Waratek上，既然德意志銀行已經認可了這個產品，那麼這個產品應該也值得你花時間研究一下。
問：Java常被拿來和Scala做比較，這兩種語言的設計目的有什麼不同？在未來，這兩種語言是否可能發展方向完全一致？
Java和Scala是有著很大不同的語言。之前我們談到Java的設計哲學，現在我們可以說Scala的設計思想，以及它們之間有什麼不同。 Scala原本是來自學術界的語言，最開始Martin Odersky創造的語言叫做Pizza，那時Java還是版本4，這時候Pizza開始逐漸加入了一些類似Java範式的功能，Java 5中也加入了一些Pizza的功能作為範式。
Martin是個很聰明的人，Scala也有很多很棒的設計。但是同時，這個語言也有自己的問題。有時候它被稱為「廚房水槽」語言，可見人們對這門語言又愛又恨。這個比喻的意思是：水槽裡面裝了各種數量過多的東西。這確實是Scala的一個問題，它的功能太多了。有一種語言設計的準則，同時也是Java設計過程中的重要原則──保守。具體說來，就是每當你加入一個新功能的時候（《Java程式設計師修練之道》14頁談到了一個具體的例子），可能你也造成了新的問題。如果你的語言有200種特性，而這個時候你想再加入一個，我需要檢驗它和所有其他特性的互動情況。對於Scala來說，它總是頻繁地加入新的功能。要知道這些特性之間的互動情況是很困難的。就算Scala有一個很靈活，能夠擁抱改變的社區，語言特性的變動也是件不容易的事。所以你會發現雖然Scala擁有很多優秀的工作性能，但是你需要決定哪些特性是你想要的，而哪些特性是你不能碰的。當你在團隊中編程的時候，這不是個問題。真正的問題在於，現代社會的軟體棧從來都不是僅僅依賴程式碼，問題來自於函數庫。有一些Scala特性的動作不僅影響目標對象，還會影響其他一些東西。 Scala的特性越多，這些問題就更容易互相重疊。
另外，他們一直都糾結於二元相容的問題。 Java、Sun以及Oracle一直都認為這是對Java來說最重要的設計理念，所以我可以用Java 1.0寫程序，編譯一下，放到Java 8的虛擬機中，仍然可以運行，而且運行速度會比以前快很多倍。而Scala從未做出這方面的承諾，即使是上一個版本也會出問題。在函數庫空間中，這個問題就更嚴重了，我知道很多專案都放棄了Scala，就是因為每次只要升級函數庫，整個系統就會崩潰。
所以說，這兩種語言的設計思想很不相同。人們總是喜歡新鮮事物，第一個嚐鮮的人也會第一個享受到很多好處，但是在更多的情況下，人們更願意做第二個嘗試的人。你可以觀察第一個人犯下的錯誤，然後從中學習。而Java就是這樣一個從別人的錯誤中學習的語言。我剛剛提到過程式設計師的金字塔，我認為Scala並不適用於底層，它的作用更多在於為最頂層的程式設計師們激發思考。而Java是一種適用於整個金字塔的語言，而且它對底層和中層的程式設計師尤其適用。我相信在未來的許多年內都會有一個強大且健康的Scala社區，我也希望能和他們一起交換思想。但我並不認為Scala會從一種小眾語言成長成一種大眾語言。現在地球上可能有上百個Scala程式設計師，但這個數量頂多也就是Java程式設計師的百分之一，而這個比例很可能不會繼續增加了。
