編譯 | 屠敏、王啟隆

出品 | CSDN（ID：CSDNnews）

1995 年，一個叫 Oak 的語言悄悄登場，后來它改了個名字，叫 Java。

它曾一度被譽為“一次編寫，到處運行”的典范，堪稱編程語言教科書中的傳奇；它也曾是企業級軟件開發的絕對主角，被寄望于主導移動互聯網的未來。然而，這些年隨著 Python、Go、Rust 等語言不斷崛起，“Java 已死”的聲音不絕于耳。特別是在 AI 浪潮席卷而來的當下，這門寫了三十年的語言仿佛逐漸失去了話語權，甚至被一些人認為已經“過時”。

可現實并非如此。Java 依然活躍在全球無數開發者的工作流中，支撐著大大小小的關鍵系統，版本號也悄悄地爬到了 24。

就在 Java 迎來 30 歲生日之際，專注于 Java 和 OpenJDK 社區技術動態的播客 FooJay 請來了 Java 的締造者 James Gosling，主持人 Frank Delporte 與之進行了一次特別的深度對話。James Gosling 怎么看 Java 的三十年風雨歷程？，如今真的退下來了，還是“假退休，真折騰”？

來源：維基百科

這期訪談中，我們將一同探尋 Java 的起源、了解 Gosling 對編程世界革命性的影響、三十年來的持續演進，以及 Gosling 對這門語言未來走向的深刻洞見。從那個石破天驚的 Beta 版，到“一次編寫，到處運行”的理念，再到驅動全球數十億設備。這段傳奇，將由 Java 之父，一切的開創者，詹姆斯·高斯林親口講述。

Java 的誕生：原本只是想修修 C++ 的邊界問題

主持人：5 月 23 日是 Java 首個 Beta 版于 1995 年發布的三十周年紀念日，我們榮幸地推出了史上首次單嘉賓播客。而這位嘉賓，分量十足——他就是 Java 的締造者，詹姆斯·高斯林。你近來生活如何？

詹姆斯·高斯林：其實，那更像是 35 年前的事了……

主持人：或許我們應該把時光倒回 35 年前。你當初為何以及如何開啟這項事業的呢？

詹姆斯·高斯林：故事始于 90 年末、91 年初。我們一群人注意到，計算機技術正滲透到各個角落。它不再僅僅局限于數據中心、科研人員的辦公桌之類的場景。我們感覺到數字系統正在擴張，當時我們對此相當敏感，但似乎整個行業，包括 Sun 公司，對此卻視而不見。

于是斯科特（Sun 公司共同創辦者之一）說：“好吧，你們這些愛發牢騷的家伙，去研究研究這個吧。”

我們就去了。我們做的一件事就是走訪各行各業的人士，了解他們如何在自己的產品中運用計算機。從錄像機制造商到電梯、火車頭的工程師，我們進行了大量的實地考察。那幾個月四處拜訪，會見歐洲、亞洲那些正在創造事物的人們，真是一段非常有趣的時光。

期間浮現出許多問題，有些著實令人沮喪。這些人的一個共同點是，他們都在將網絡融入一切，但他們卻在重新發明網絡。他們做的那些發明，計算機科學在幾十年前就已經做過，并且深知其為何會失敗。他們大量使用串行線路，卻沒有足夠的糾錯機制。那些從事工業自動化的人還在用 8 位地址。天啊，8 位地址根本無法擴展，16 位也仍然不夠。

然而，在與這些人討論需求時，我們也從他們身上學到了東西。他們從不提及安全性和可靠性。并非因為他們不在乎，而是因為安全性和可靠性是如此至關重要，以至于根本沒必要列在清單上，那就像說“哦，我們要蓋房子，得記得往里面放氧氣”一樣。這是一種不言而喻、絕無妥協余地的要求。

當時，性能是計算機設計的一切。為了提升一點性能而犧牲一點可靠性是很常見的做法。那個時代我最愛舉的例子是除法的實現方式：他們用牛頓迭代法求解器，而不是你在高中學到的長除法（或者至少是其電子版）。所以他們的除法運算非常非常快，但低位精度卻有些馬虎。人們總是這樣做。即便在 Sun 公司內部，人們也會做出一些讓我們這些人感到不安的權衡。對很多用戶而言，這可是人命關天。如果你在為火車頭或電梯構建控制系統，一旦出錯，通常就會血濺當場。第一要義，絕不能把客戶給“干掉”。

主持人：這確實是條鐵律。但我很驚訝你提到火車頭，而如今使用 Java 的人，通常認為它是一種服務器語言，部署在大型服務器上。

詹姆斯·高斯林：這正是分歧之處的全部來源。兩個方向其實都對。企業市場有更多的資金，因此 Sun 公司最終將大部分投資投入到這方面。這種發展軌跡多少有點出乎意料。但盡管如此，當你回頭看看人們實際用 Web 服務做的那些事——無論是航班調度、打車服務，還是城市公共交通系統的運營——我們最初想象的是像電梯這種規模的小型設備，而其他人則在構想類似倫敦地鐵這樣的大系統。雖然規模不同，但如果系統崩潰，后果可能是一樣嚴重，甚至更糟。所以，一旦出現故障，代價會非常慘重。

我對 C 語言最不滿意的一點，就是它太容易寫出難以修復的錯誤，而這些錯誤往往會帶來非常隱蔽、難以診斷的問題。邊界條件實在太多了。

當我們啟動這個項目時，我們首先去調研用戶到底在做些什么，理解他們的工作方式。然后我們開始構建原型——因為我們是工程師，更擅長用代碼說話，而不是寫白皮書。原型的一個優勢在于，它迫使你在腦中真正具體化問題。我們當時有幾位軟件工程師、幾位硬件工程師，還有一位非常優秀的商業伙伴。

隨著我們不斷思考從用戶那里收集到的需求清單，逐漸發現，軟件工程中一些“標準做法”其實不斷制造問題。最大的問題都集中在可靠性和安全性上。而這兩個方面，在某種程度上其實是密切相關的，甚至可以說本質上是一回事。因為世界上很多安全攻擊，本質上就是程序錯誤。當然，也有一些攻擊是源于極端的愚蠢——比如把 root 密碼設為空。你說這是個錯誤，還是徹頭徹尾的無能？你自己判斷吧。

我們一開始用的是 C，但很快就覺得不行……后來又嘗試了 C++，但也發現問題依舊。

于是，我就成了團隊里那個說“我們是不是該從方法論層面解決這些問題”的人。結果就是，一旦你開始嘗試去解決這些方法論問題，很快就會被帶著一步步走遠。最初只是想修補 C++ 里那些討厭的邊界情況，沒想到最后發展成了一件完全不同的事。

主持人：確實。如今它已經是一門完整的語言，還發展出一個龐大的社區。這真的非常了不起。數百萬人正在使用你創造的 Java。你有什么感受？

詹姆斯·高斯林：真的感覺非常棒。讓我最感動的是，每當有人走過來說：“謝謝你，是你讓我擁有了這樣一份事業。”我總是有些不知該如何回應——因為這實在太美好了。

主持人：我自己也必須對你說聲謝謝，因為你對我來說就是那樣的人。我從 10 歲起就開始玩 Commodore 64，我是那個時代的人。后來，我當了幾年電影剪輯師，但最終重新燃起了對編程的熱情——因為我需要找一種辦法把視頻放到網上。不知道怎么回事，最后我就選了 Java。我試過其他語言，但唯獨 Java 吸引了我。

我一直無法理解 C 和 C++，它們不符合我的思維方式，我也說不清為什么。但在 Java 里，我什么都能讀懂。我只需要 Java 和 JavaFX，就能做出我想要的任何東西。它真的讓我找到了新的職業方向，也讓我可以靠編程謀生。

千年蟲危機，如何意外助推了 Java 的普及

詹姆斯·高斯林：看著它如此廣泛地傳播，有時也會帶來一些負面影響。整個千年蟲（Y2K）事件，現在想起來還有點心驚膽戰。

因為 Y2K，許多人從 COBOL 遷移到了 Java。而我，正是 `java.lang.Date` 的作者。我大概花了一整個星期在它上面。所有新的、那些花哨的日歷類都是在 2000 年之后才出現的。

但那一晚，我徹夜難眠。我關注著每一個聊天頻道，想看看發生了什么，有沒有出什么岔子。當然，我們之前已經進行過各種演練，把電腦的時鐘撥快一個月之類的，所以我們已經經歷過很多次 Y2K 了。但真正的 Y2K 是不同的。

主持人：但事后仍然有人說：“嗯，沒那么糟。他們說世界會停止運轉，但其實還好。”但這難道不是因為所有那些工程師們已經為可能發生的情況努力了好幾年嗎？

詹姆斯·高斯林：完全正確，正是如此。作為一名工程師，最麻煩的一點是，你工作的最佳狀態就是無人察覺。如果真發生了什么“激動人心”的事，那很可能就是你搞砸了。如果你是那種靠著阿諛奉承和腎上腺素過活的人，或許工程領域不適合你。你必須從“橋沒有塌”這件事中獲得快感。

主持人：就像幾年前我們遇到的 Log4j 問題一樣。出現了一個漏洞，所以那個庫突然成了大問題。但另一方面，人們在那個庫上投入了大量精力，很多人使用它并簡化了他們的工作。然后突然因為那一個問題的出現，整個系統就名譽掃地了。但這就像你說的，如果你什么都不做，就不可能做錯任何事。

詹姆斯·高斯林：沒錯。

Java 路上有沒有“后悔藥”？

主持人：Java 中是否有很多類似的事情讓你覺得：“我犯了個錯誤？”人們可能會說是空指針或空指針異常。那是個錯誤嗎？

詹姆斯·高斯林：很多這類事情，就像是在玩“打地鼠”游戲。你知道那種你要敲打冒出來的地鼠的游戲。工程就是這樣。而且總是有權衡取舍。我們最擅長處理的是工程上的權衡，但有時社會學層面的權衡更難。

我經常被詬病的一件事是泛型。94 年的時候，關于泛型有過一場大爭論。有些人堅持：“必須要有泛型。”我當時想：“好吧。”因為這些人用過泛型，他們來自 C++ 世界。“但是 C++ 的泛型糟透了。我們必須把它做對。”

然后問題就來了，什么是“對”的？我跟很多人聊過。編程語言中的泛型，在當時是一個重要的研究領域，但對于何為“良策”，眾說紛紜，莫衷一是。

有一派人說：“在我們搞定泛型之前，什么都不該發布。”但很明顯，這會耗費我們兩三年的時間。如果我們推遲兩三年，互聯網正在爆發式增長，那可是爆發的極早期階段。如果我們等上幾年把它做好，我們就會錯過整個浪潮。如果我隨便塞進去一個東西，結果是錯的——我估計有 99% 的可能性——那么撤銷它將會非常困難。當時有很多面向對象的編程語言沒有泛型，它們也運行得很好。

最終，幾乎形成了一場關于 Java 泛型應該如何實現的全球競賽。一個大問題是它如何與內省（introspection）交互。沒有人能提出一個可行的方案。這是一個關于所謂“具體化”（reification）的爭論。如果我們不惜破壞當時存在的每一個應用程序，我們本可以實現具體化。

主持人：我認為這完全違背了 Java 的哲學。

詹姆斯·高斯林：當你擁有一個龐大的用戶社區時，你就肩負著重大的責任，不能把他們搞砸。直到今天，我還會從朋友那里聽到：“那是個錯誤。”而我會說，不，那不是錯誤，那是一種妥協。

主持人：作為 Java 的創始人和最初的創造者，你當時的工作方式與現在 Java 通過 JEP 和六個月發布周期的演進方式之間，是否存在巨大差異？我猜存在的。

詹姆斯·高斯林：完全不同，天壤之別。在發布之前，我可以在一個下午做出翻天覆地的改動。沒什么大不了的，輕而易舉。而且我經常這么做。有一天我刪掉了 `goto`，因為我實在受夠了它的愚蠢。我默認繼承了 C 和 C++ 的很多東西，以便讓人們感到熟悉。但是 `goto` 是那種會導致各種奇怪邊界情況的東西。一個下午，我真的就是不耐煩了，做了一些有限的研究，然后“砰”，它就消失了。那是一段極其奢侈的時光。

硅谷流行著一個令我情感極為復雜的工程原則，你經常從埃隆·馬斯克和馬克·扎克伯格這樣的人口中聽到：“快速行動，打破陳規。”當你在構建原型時，我完全贊成。但一旦有了用戶，他們依賴你的產品，游戲規則就完全變了。我對“快速行動”本身沒意見。

主持人：但不是破壞。

詹姆斯·高斯林：但不是破壞。而且，“快速行動”常常被曲解為隨心所欲地做些蠢事，看看人們會怎么抱怨。這對用戶體驗來說可不妙。

Java 的“一次編寫，到處運行”理念依然成立！

主持人：很多人對此感到驚訝：非常古老的 Java 應用程序仍然可以在最新的運行時上運行。這正是整個 Java 體系的強大之處。

詹姆斯·高斯林：很久以前，為了一個演示之類的，我寫了一個 Swing 應用來玩紙牌。那個二進制文件我還留著。它是為 Java 6 或 7 之類的版本編寫的。我現在仍然會運行它，而且頻率高得有點不好意思，因為它就是紙牌游戲。

但關鍵是，那個二進制文件是大約 20 年前編譯的，現在依然運行良好。我在我嶄新的 Mac Studio 上玩過它，在程序構建時還不存在的架構和操作系統上。它運行得非常棒，驚人地好。所有的圖形動畫都如絲般順滑。

主持人：這就是“一次編寫，到處運行”的理念。它從一開始就存在。你認為它現在依然成立嗎？

詹姆斯·高斯林：這個理念今天依然非常成立。雖然還稱不上完美，但已經非常接近了。

我特別喜歡的一點是，我不需要反復編譯同樣的代碼；也不需要為了適配市面上各種不同類型的設備，去生成二三十個不同的二進制文件。比如我那個紙牌游戲，它生成的 Linux 二進制文件，同一個文件拿到 macOS 上也能直接運行。這種感覺真的很棒。

當然，有時候還是會有些“漏風”的地方，比如你用到了 shell 腳本之類的東西，那就會比較麻煩。但從整體上來說，Java 并不比其他平臺更糟糕。真正讓人頭疼的異類，其實是 Windows。

主持人：為什么這么說？

詹姆斯·高斯林：因為 Windows 和其他系統不太一樣。除了 Windows，大多數操作系統都遵循了類似 Unix 的架構。甚至現在 Windows 自己也引入了 Linux 子系統——他們也是被迫這么做的，因為在云環境中使用 Windows 實在太貴了。

主持人：我是樹莓派的忠實粉絲，背后就堆了一大堆。

詹姆斯·高斯林：我也有樹莓派，如 Jetson Nano。

主持人：這些又便宜又神奇的小板子，是用來做 Java 實驗和運行各種 Java 程序的絕佳平臺。我有幾個 JavaFX 應用，動畫效果非常重，但在這些設備上也能跑得很順暢。

詹姆斯·高斯林：對，這真的很棒。說實話，JavaFX 一直是我最喜歡的技術之一。那個團隊干得太出色了——尤其是在 Oracle 基本放手不管之后，他們仍然堅持做出了很多令人驚嘆的成果。

主持人：你認為如果 JavaFX 能得到例如 Oracle 更多的青睞，它會有更大的市場份額嗎？

詹姆斯·高斯林：我當然曾抱有希望。桌面應用的世界已經變得非常碎片化。我覺得很有意思的是，對于移動設備，基本上有兩個基礎平臺，Android 和 iPhone。它們竭盡所能地想要與眾不同，非常喜歡保持各自的獨特性。我完全理解這兩個陣營為何要這么做。但從我作為開發者的角度來看，這簡直太糟糕了。盡管 Android 最初有點像 Java 的東西，但他們完全破壞所有圖形和 UI API 的方式簡直是……我還是別評價 Android 了，因為它簡直……

主持人：我們曾經有過 Java 手機。我想它從未真正上市，但我們是否可能擁有 Android、iOS、Java 手機并存的局面？或者 Java 手機甚至會比其他兩者更好？

詹姆斯·高斯林：當然。Java 在 iPhone 上運行得很好。問題在于，從一開始，iPhone 的服務條款就不允許使用 Java 進行部署。所以那些真正想做 Java 應用的人——這也是 JavaFX 團隊大顯身手的地方之一——他們開發了實質上的靜態交叉編譯器，可以將 Java 世界的代碼編譯到 iPhone 的工具鏈中。然后你就可以發布應用，可以在 iPhone 商店發布 Java 應用，但你必須經歷那個瘋狂的工具鏈跳轉過程。

主持人：這確實很瘋狂。我在這方面做過太多失敗的實驗了。但是，我們需要做什么才能讓 Java 成為移動和嵌入式開發的平臺呢？

詹姆斯·高斯林：我認為作為開發者，我們無能為力。

主持人：不行嗎？

詹姆斯·高斯林：這需要 Android 陣營和 iPhone 陣營開始以完全不同的方式思考這個世界。而這對我來說似乎不太可能。

主持人：他們是太大的公司在競爭。

詹姆斯·高斯林：“一次編寫，到處運行”這個理念，某種程度上源于 Sun 公司。那時在計算機市場上，尤其是在早期，Sun 只是一個小角色。想讓開發者為 Sun 的平臺寫軟件非常困難，人們常常會說：“你們的市場份額才這么點兒，而那邊那些公司的市場份額那么大。”

是的，為他們的平臺開發軟件很糟糕，但這不是工程師說了算的，而是業務部門的決策。他們會說：“沒錯，但如果我們能把軟件賣到那個平臺上，可能就能多賺五倍、甚至十倍的錢。”

Java 的意義就在于，它讓你可以把所有小玩家聯合起來。于是，小玩家也能和大玩家站在同一平臺上。

如今我們所處的時代，硬件生態系統已經高度整合，遠不如過去那樣多樣。如果你現在買一臺筆記本電腦，基本只剩兩個選擇，或許勉強算上第三個，但那也只是“半個”。

像你我這樣的人，會覺得 Linux 筆記本是一個可行的選項。但對 99% 的普通用戶來說，根本不會考慮。主持人：這其實挺奇怪的，因為 Linux 在那些更小、更便宜的電腦上運行得更流暢。詹姆斯·高斯林：對，絕對如此。主持人：所以我一直不太明白，為什么學校都迷戀 Chromebook 和 Windows 電腦。明明還有更好的選擇，但我覺得這完全是市場營銷的力量。他們太擅長營銷了。詹姆斯·高斯林：是啊，這里面確實有市場營銷的作用，也有路徑依賴的成分。我一直對那些堅持什么都用 Windows 的公司感到沮喪，多半只是因為他們已經習慣了。Windows 長期以來一直存在嚴重的安全問題，雖然他們現在確實在努力改進，但仍然是所有平臺中安全性最差的。 Linux 可能是最安全的，其次是 macOS，或者說是 iOS，在我看來這兩個差不多。蘋果的優勢在于，一旦發現安全漏洞，他們可以在幾天之內將修復推送到全球所有設備上。而 Windows 想做到這一點則要困難得多。
Java 在 Docker 中啟動挑戰

主持人：如果我們回到 Linux，你有沒有預想到，整個云系統——在你最初設計 Java 時還根本不存在——最后會有很大一部分運行在 Java 上？把它做成一門服務器端語言，是最初的目標之一嗎？

詹姆斯·高斯林：沒有。你可能不信，第一個 Java 應用服務器是在 1994 年寫出來的。所有后來屬于 Java EE 核心的 API，實際上很多都起源于那一年。比如 Servlet 類，就是那時候寫出來的。一個常被忽略的事實是，我就是寫出最初那個Servlet類的人。那時我只是隨便試試，心想：“嘿，這個東西挺好用的。”

但后來事情變得有點不堪回首了。我被告知要把這些東西扔掉，因為 Sun 有一些合作伙伴不希望看到我們在這方面形成競爭。現在回頭看，我敢說那已經觸犯了《謝爾曼反壟斷法》。但確實就是這么回事。

主持人：我覺得沒人能預料到后來會演變成今天這個樣子。很多人都說：“Java 不適合跑在 Docker 容器里。”但 Docker 在你設計 Java 的時候根本還沒出現。

詹姆斯·高斯林：是的，不過如今大家已經找到了很多辦法，讓 Java 能很好地在 Docker 容器中運行。而且也不僅僅是 Java 在容器里遇到問題——很多語言都有類似的挑戰。Java 在 Docker 里的主要問題是啟動時間。但其實 Docker 本身也有啟動時間的問題，因為它需要先啟動 Linux 系統。

他們為加快 Linux 啟動所做的優化，和我們為加快 Java 啟動所要做的事情幾乎是一模一樣的。但歸根結底，這還是一個工程上的權衡問題。當年我們開始做服務器端應用時，主流的模式是：你啟動一個服務器程序，然后就讓它長期運行。所以我們會把所有精力集中在長期的高吞吐性能上。而很多能夠實現這種性能的優化手段，其實是會犧牲啟動速度的。

在很多系統中，你如果想獲得更快的啟動時間或更一致的響應時間，就得在某種程度上犧牲吞吐量。

就拿最基本的例子來說，比如哈希表。大家都覺得哈希表非常快——確實，在讀取數據時，它真的非常快。在寫入數據時，它通常也很快。但偶爾，它會變得擁堵，你就得重組哈希表，做一些調整。幾乎所有的系統在底層都會有很多小聰明來追求高性能，但它們始終需要不時做一些結構維護的工作，來確保系統穩定。

如果你稍微了解一下 HotSpot，就會發現它簡直是工程學上的奇跡。它所做的那些優化，令人嘆為觀止。即使到今天，我仍然會對它在代碼生成方面的表現感到驚訝——它有時候甚至能在某些基準測試中擊敗 LLVM。

至于垃圾回收器，它的表現已經好得離譜。

主持人：是的，我剛加入 Azul 的時候，最讓我驚訝的就是這一點。我當時接到的第一個任務，就是寫一篇關于不同垃圾回收器的博客文章。雖然我已經做了十多年 Java 開發了，但從來沒有為垃圾回收操過心，因為它總是能“自動”處理好。

但當我寫那篇文章，開始和那些親自實現各種垃圾回收器的人聊之后，我才意識到，這背后有多么復雜的技術體系！有那么多專業知識和工程細節，都是為了讓開發者根本不需要去考慮垃圾回收本身。這才是真正了不起的地方。

詹姆斯·高斯林：沒錯，垃圾回收器令人驚嘆的地方正在于此——它既消除了大量復雜性，又容納了巨大的系統復雜性。

很多人都喜歡 Rust 的內存管理，我自己其實也挺喜歡的。但問題是，一旦你的數據結構變得復雜，比如有很多交叉引用、緩存層級等等，Rust 的模型就會開始變得吃力。而 Java 的垃圾回收器則能把這些復雜的數據結構處理得井井有條，而且運行效率極高。

我現在還會碰到一些人，他們說垃圾回收太慢了，一次回收得幾分鐘……

拜托，抱歉，幾十年來，垃圾回收都不需要幾分鐘了。

主持人：很多批評 Java 的人，其實是很久以前用過 Java，對后來社區的貢獻和這些年版本的改進完全不了解。

詹姆斯·高斯林：時下，一個中規中矩的垃圾回收器都能把最大暫停時間控制在一秒以下。而真正優秀的垃圾回收器，最大暫停時間可以壓到 5 到 10 毫秒之間。

當然了，之所以存在多種不同的垃圾回收器，正是因為它們在吞吐量和延遲之間做出了不同的權衡。如果你想讓系統負載更低，那就得接受響應時間可能會更不平穩。就像我們剛才說的哈希表例子一樣——你想讓它“超級快”，那就得接受偶爾會有性能波動。你可以通過各種算法來平滑這些波動，但無法真正消除它們。

不過也有一些回收器，能做到完全沒有性能抖動，但代價就是吞吐量會被拉下來。

三十年前，如果你想獲得一致的響應時間或低延遲，代價可能是 30% 的吞吐量損失。而現在，如果你要實現非常低的延遲，吞吐量的犧牲只需要 1%-2%。

垃圾回收是計算機領域里最不顯眼、但也是最精彩的技術之一。當你開始讀關于垃圾回收的學術論文時——我的天啊，那真是一個奇妙紛呈的世界。

主持人：而且令人驚奇的是，盡管系統變得越來越大，使用的內存越來越多，它們卻改進了這么多。

詹姆斯·高斯林：另一方面，我們也有了更多的 CPU 作為底層支撐，所以所有這些東西的進化速度真是驚人。這在某種程度上也是 Java 在嵌入式系統上運行時偏離初衷的地方。在服務器世界，沒有哪個系統會只有 1G 內存。如果你買一臺新的樹莓派，通常有 8 到 16G 內存。我面前這臺新的臺式電腦有 256G 內存。

當然，所有這些內存都是為了施展一些能讓程序運行更快的技巧。如果你想適應小內存環境，有些事情你就做不了，因為你沒有足夠的空間。同時，大量的內存也可以掩蓋某些工程上的草率。

詹姆斯·高斯林：幾年前我做的一個項目中，最讓我頭疼的問題是它占用了大量內存。深入調查后我們發現，雖然表面上看起來是 Java 虛擬機占了很多內存，但其實真正消耗內存的是那些引入的庫。Java 生態系統的一大樂趣在于，幾乎所有東西都有豐富的選擇。但這也是最大的痛苦之一。

我最討厭的東西之一是 HTTP。在我們分析的那個應用里，竟然出現了五個完整的 HTTP 棧。首先是 JVM 自帶的 HTTP 棧；然后是 AWS 的庫——出于我不理解的原因，他們覺得需要定制一個專用的 HTTP 棧；再是谷歌的庫——只要你用到任何一個谷歌庫，它就會把整個“谷歌宇宙”的依賴閉包一股腦兒地帶進來，其中也包括谷歌的 HTTP 棧；另外，只要你用了任何 Apache 的庫，Apache 也有自己的 HTTP 棧。對這些組織來說，自己造一個 HTTP 棧通常比去協調一個所有人都能接受的通用方案來得容易多了。雖然我們完全可以做到后者，但現實就是這樣——“快速行動，打破陳規”。

主持人：但這也是開發者的責任。我參與過一些項目，里面竟然用了三個不同的 XML 庫。

詹姆斯·高斯林：是的，這種情況太常見了。還有 JSON 庫也是這樣。幸運的是，在 JSON 的世界里，Jackson 很早就脫穎而出，而且幾乎徹底占據了主導地位。當然，Jackson 其實還分兩個版本：標準版和 Jackson Jr.。標準版功能更多，速度也更快，這是有原因的，但它也大得多。而 Jackson Jr. 更輕量，我更喜歡它，因為我對內存使用特別敏感，喜歡精打細算、按字節來衡量。

不過在那個充滿各種 HTTP 棧的項目里，我們最后還是用了兩個版本的 Jackson。因為我傾向于只用 Jackson Jr.，但其他人很喜歡完整版的功能。我其實也喜歡 Jackson 的那些強大功能，只是我在“字節計較”這件事上非常頑固。

你看著這些東西運行，尤其是像 JSON 這種場景——說到底，對于生成 JSON，你甚至連 printf 就夠了。我還挺喜歡那種直接用 printf 生成 JSON 的方式，雖然我知道這會讓我的不少同事感到非常不安。

談 Java 與其他編程語言之爭

主持人：你剛才簡單提到了 Rust 作為 Java 的競爭對手。但我們如果把視角從語言擴展到整個 JVM 生態，你怎么看那些構建在 JVM 之上的語言？因為我們一直在討論 Java 作為一門語言，但它其實是語言和運行時環境（JVM）的一體組合。而像 Kotlin、Scala、Clojure 這些語言，其實都是運行在同一個虛擬機上的。你如何看待這種演變？

詹姆斯·高斯林：我覺得這些語言都很酷，我也很喜歡它們。Scala 是我早期就非常欣賞的一個成功案例。但說實話，它還沒吸引到我讓我愿意放下手頭正在做的事。我并不是那種會迅速跟風嘗鮮的人。我就是個穿著 T 恤和牛仔褲干活的普通程序員。

Clojure 也很酷——如果按“酷炫指數”來說，我非常喜歡它。但 Clojure 的問題在于，它和大多數人的思維方式太不一樣了。它采用 Lisp 風格的語法，而且對編程有一種非常極致的函數式理解。我自己其實是函數式編程的忠實粉絲。

不過，函數式編程風格在某些地方很適用，在另一些地方就未必了。我在寫 Java 代碼時也經常采用函數式的方式，這是我做的另一件會讓其他工程師崩潰的事（笑）。比如，我寧愿用遞歸，也不愿用數組。但這只是我個人的偏好而已。

“說不再需要軟件開發者的老板，就是在自欺欺人”主持人：一個完全不同的話題。我在你 LinkedIn 的一條消息中看到，你也要求人們思考自己的工作及其責任。如果你在一家公司擔任程序員，被要求做一些你認為邪惡的事情，比如奇怪的營銷技巧之類的。作為開發者，我們對如何使用我們的工具和開發者能力負有多大責任？

詹姆斯·高斯林：我一直堅信，如果你的公司要求你做一些不道德的事，你應該直接走人。

當然，首先你也可以和他們談一談：“你們真的想這么做嗎？你們真的理解這么做的后果嗎？”有時候，你可能會讓他們意識到：“哦，你說得對，我們不該這樣對待客戶。我們確實沒考慮到長期影響。”但更多的時候，他們只會說：“哦，是的，沒事的。”

你會遇到一些曾在醫保公司工作過的人，聽到他們講的一些故事真的讓人震驚，比如：“他們居然會那樣做？”

這其實也和現實情況有關。如果是在就業機會很多的時候——軟件工程師過去就經常處在這種環境下——那么說走就走也很容易。

主持人：沒錯，的確如此。

詹姆斯·高斯林：現在就不一樣了。現在的就業市場非常非常艱難，尤其是在美國。美國現在簡直就是一團糟。

我在 LinkedIn 上寫的那篇文章，談的是“叫板的底氣錢”（fuck you money）這個概念——這個詞其實已經存在幾個世紀了。意思是說：你是否有足夠的積蓄，能在必要的時候對雇主說“去你的”，然后直接走人？如果你沒有這份底氣錢，你在某種程度上就成了奴隸。

而“奴役”也可以以別的形式存在。比如說，如果你是一個家長，孩子又有嚴重的健康問題，那么考慮到美國醫療體系的運作方式，一旦你離職，可能就會影響到孩子的治療和健康。從雇主的角度看，這反倒成了美國糟糕醫療體系的一種“優勢”——它讓員工在某種程度上被綁定在公司里。這也許在技術上算不上真正的奴役，但感覺真的非常接近了。

主持人：隨著人工智能帶來的全面競爭，選擇會不會變得更加艱難？對于很多總監、工程師、很多老板來說，他們認為他們不再需要軟件開發者了。

詹姆斯·高斯林：我認為他們是在自欺欺人。而且我覺得，有些情況簡直近乎滑稽。一些人工智能領域的人，比如 OpenAI 這樣的公司一直在說：“啊，你不需要文案撰稿人了，你不需要這個那個了，因為人工智能可以做所有事情。”但現實是，AI 目前能做的事情非常有限，效果也往往不如人意。

比如有家律所嘗試用 AI 來撰寫法律文書，結果文書看起來像那么回事，但內容完全是胡扯，最后還因此受到了處罰。這類例子比比皆是。

但軟件工程又不太一樣。它有一個獨特的特性，就是我們有“庫”這個概念。如果某件事你做過一次，下次你很可能就會把它封裝成一個庫，以后復用。很多人用的東西還會變成開源庫。換句話說，開發者并不總是在重復造輪子，除非你還在學習階段。

AI 工具，尤其是像 ChatGPT 這樣的生成式系統，本質上是基于大量已有代碼訓練的，它們在“插值”方面表現不錯——也就是在已有知識的基礎上做填充和改寫。但這并不是軟件開發的難點。

真正有挑戰的是“外推”——也就是解決那些沒人遇到過的新問題。軟件工程的樂趣正是你經常在做全新的東西，而不是一遍遍復制已有的方案。

我喜歡拿土木工程打比方：你建一座橋要花很多精力，但建下一座橋、再下一座橋，成本都很高。而在軟件工程里，一旦你寫好了一個模塊，復制它幾乎是免費的。這種“從零到一”的創造，是 AI 目前很難替代的。

我看到的像 ChatGPT 這樣的工具的用途，主要是在學習方面。我發現自己把它當作一種自動化的幫助系統。就像，“我該如何寫一段代碼來連接這個和那個？”它有一定的準確率。

主持人：你對初級程序員有什么建議嗎？如果他們遇到糟糕的經理，如果他們必須選擇一門語言。你對新手有什么好的建議嗎？

詹姆斯·高斯林：當你樂在其中時，事情總是更容易。我一直發現，如果我從事的是我真正著迷的項目，我會做得更好。

軟件工程的一個好處是，軟件是一種工具，它被用于許多不同的行業。所以我更傾向于根據項目所處的環境來選擇工作。

我有點像個太空迷，我非常喜歡航海、船只之類的東西，而且我有幸從事過一些讓我能接觸到很多這些事物的工作。當我有幸能夠真正選擇工作時——我的數學還沒好到能成為一名物理學家，但我可以為物理學家工作，并且過得很開心。如果你足夠幸運，并且能找到適合你的那種環境。當就業市場像現在這樣緊張時，就有點像“乞丐沒得挑”。然后通常就只能忍氣吞聲，做你需要做的事情，然后等待更好的時機。

為什么你不做 Java 的終身仁慈獨裁者？

主持人：如果回顧你開始 Java 的這 30 年，你能指出幾個重要的時刻嗎？可能有很多，但你能挑幾個嗎？

詹姆斯·高斯林：有幾個“顯而易見”的關鍵時刻。比如 Java 的正式發布，再比如我們當時跟網景（Netscape）那種瘋狂的合作關系，還有與整個行業中其他勢力之間的一些微妙互動。

我們也因為沒有更早地開源而受到不少批評。其實從一開始我們就提供了源代碼，但用的不是開源社區真正推崇的那種許可證。這里面牽涉很多復雜的問題，但從我們的角度來說，最大的擔憂是：當時有好幾家非常強勁的競爭對手，他們幾乎是鐵了心要“干掉我們”。如果我們早早使用一個完全開放的許可證，那無異于把武器遞到對手手里，簡直像是發了一張“開火許可證”。

我們當時預估，大概有五六家公司在盯著我們，只等我們一開放代碼，就要把我們碾碎。所以我們處在一個非常矛盾的局面里：理智上知道開源可能對發展更有利，但情勢又逼著我們不得不防守。這不是個容易做的決定。

主持人：聽起來那時候也有很多“戲劇性”的瞬間？

詹姆斯·高斯林：有的，甚至可以說比電視里的劇情還精彩。比如，有一次我們正與 ECMA（歐洲計算機制造商協會）談判，想把 Java 納入為他們的一個標準。當時的氣氛看起來很順利，大家在技術細節上已經基本達成一致。

但我們不知道的是，有三家大型公司（我就不點名了，你大概也能猜到是哪幾家）一直在暗中跟 ECMA 協調。等我們準備好召開一次會議、敲定標準時，ECMA 的代表突然變臉——就在前一天晚上我們還一起吃飯、意見完全一致——卻在會上宣布：新計劃是把 Java 分成三部分，語言、虛擬機和標準庫，每一部分由那三家公司中的一家負責，而 Sun 公司將不再在標準制定中擁有任何正式地位。

換句話說，那三家公司將分別掌控 Java 的三大核心組成，而我們這個發明者徹底被排除在外。這對我們來說簡直是晴天霹靂。

更關鍵的是，Java 是一個生態系統，不是幾段獨立的代碼拼湊起來的東西。每一個部分都會影響其他所有部分。很多年里，人們都在問我一個問題：“為什么你不做 Java 的終身‘仁慈獨裁者’（benevolent dictator for life）呢？”

說實話，我很清楚那種角色會讓我這輩子做不了別的事情。而對我而言，真正重要的是，那些每天用 Java 寫代碼的人也有他們自己的關切和聲音。我一直希望他們的聲音能被聽見，因為只有真正理解開發者的需求，才能設計出他們愿意用的工具。這也是為什么后來我們創建了“Java 社區流程”（JCP）。

它當然不完美，有時候你得在會議室里跟一群人拉鋸、辯論，過程挺煩的。但這比獨裁式的決策強太多了。就像那句老話說的：“民主是最糟糕的制度——除了所有其他制度之外。”這話也同樣適用于 Java 社區的發展。

主持人：Java 目前的運作機制是否良好？它現在的發布節奏靠譜嗎？你覺得它未來 30 年會朝著正確方向發展嗎？

詹姆斯·高斯林：我其實一直對它運轉得這么好感到有些驚訝。

主持人：你是指六個月發布一次的節奏運作得不錯？

詹姆斯·高斯林：其實我并不覺得六個月的發布周期帶來了什么本質變化。在這之前，Java 是三年左右發布一個大版本，但在這三年之間，也會不斷推出構建版本（builds），很多人，包括我自己，其實都在使用這些中間版本。而這些構建版本通常也都非常穩定。

主持人：像現在我們在兩個長期支持版本（LTS）之間，也會用 23、24 這樣的常規版本。

詹姆斯·高斯林：對，是這樣。現在是每六個月發布一次版本，而 LTS 版本是每兩年發布一次，對吧？

主持人：對的，是每兩年一個 LTS。

詹姆斯·高斯林：這的確讓整個節奏更具可預測性了。

不過我對現在的機制還是有些小抱怨，比如現在引入了很多“預覽功能”（preview features）。有些功能一預覽就是好幾年，始終沒有變成正式特性。以前在三年一個大版本的節奏里，大家會在周期一開始提出復雜的新功能，然后經歷一系列小版本試驗，等最終發布大版本時，這些功能要么就成熟了，要么就被砍了。預覽狀態不會持續太久。

但現在我發現自己經常在用那些仍處于預覽狀態的功能。一方面，這挺好，因為很多有趣的特性現在都以預覽方式提供；但另一方面也挺煩，因為你永遠不知道它們什么時候會變成正式的，甚至會不會被徹底放棄。而且現在，即便是 LTS 版本，也可能帶著未成熟的預覽功能發布，這讓我有點不太舒服。

雖然大多數預覽功能最終都會穩定下來，但也有些特性到最后被直接推翻了。比如有一個叫“dot double quote”的語法（點雙引號），我當時特別喜歡，還用得挺多，但后來它被徹底移除了。我當時一想，天哪……這下完了。我現在想用最新版的 JVM 都不行，除非重寫那部分代碼，改動還挺大。

當然啦，布萊恩·戈茨（Brian Goetz）說這東西不該保留，他通常都是對的（笑）。

現在還參與多少 Java 開發？

主持人：你現在還參與討論嗎？

詹姆斯·高斯林：有時候會。

主持人：你正式退休了嗎？

詹姆斯·高斯林：我現在正式退休了，無業游民一個。除了我妻子，誰的話我都不用聽。

主持人：那么 Java 對你來說，如今還占據多大的分量呢？

詹姆斯·高斯林：其實不多了。我離開 Java 組織已經 15 年了。現在照管它的人們，我非常尊敬他們，他們非常出色。而且社區也在約束著他們，這很棒。我通常不是那種喜歡到處對人大喊大叫的人。

主持人：在結束這次訪談之前，你對 Java 社區有什么最后的話想說嗎？

詹姆斯·高斯林：保持開心！繼續創造！

原播客鏈接：https://www.youtube.com/watch?v=6iP376VwcjY

2025 全球產品經理大會

2025 年 8 月 15–16 日

北京·威斯汀酒店

2025 全球產品經理大會將匯聚互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人，圍繞產品設計、用戶體驗、增長運營、智能落地等核心議題，展開 12 大專題分享，洞察趨勢、拆解路徑、對話未來。

更多詳情與報名，請掃碼下方二維碼。