苦勞德報 for Java — 2026-06-01

2026-06-01

1. [頭版] Java 值類別語言實作 PR 正式提交，Valhalla 專案邁入關鍵里程碑

• 作者：MrSimms | 125↑ | 62 則留言

報導

（本報賈新聞／科技組報導）沉潛多年的 OpenJDK Project Valhalla，近日在開發社群掀起一波討論浪潮。開發者 MrSimms 向 openjdk/jdk 主線提交了一個規模龐大的 Pull Request（#31120），正式提出 value classes 與 value objects 的語言層實作，被視為 Valhalla 專案從研究走向落地的重要一步。

Project Valhalla 是 Java 平台長達十年的研究計畫，核心目標是解決 Java 物件模型的根本效能瓶頸——每個物件都必須在 heap 上配置記憶體，導致在大量小型資料結構的場景下，垃圾回收壓力居高不下，執行效率難以與 C++ 或 Rust 等語言抗衡。JEP 401（Value Classes and Objects）正是這項計畫的語言規格核心，定義了「值類別」——一種不具身份識別（identity-free）、可扁平化儲存的新類型，讓 JVM 得以在不犧牲 Java 語意的前提下，大幅降低記憶體配置與 GC 開銷。

此次提交的 PR #31120 並非單一檔案的小修改，而是附帶數個子 PR 的大型實作，涵蓋編譯器、執行期、反射機制等多個層面，技術複雜度極高。消息一出，r/java 社群隨即湧入超過 60 則留言，票數衝破 125 票，熱度在近期 OpenJDK 相關討論中名列前茅。

然而，社群成員普遍保持理性期待。高票留言中，davidalayachew 特別提醒興奮過頭的網友：「請記住——目前尚未承諾要在哪個版本發布！這只是一個請求 review 的 PR，僅此而已。」此番提醒獲得廣泛認同，反映出 Java 社群歷經多次「Valhalla 快來了」的期待落空後，已養成更為務實的觀望態度。

關於究竟哪個版本能見到 JEP 401 的 preview，社群意見不一。有人詢問是否有機會趕上 JDK 27，另有分析者直言：「我猜 JEP 401 preview 出現在 JDK 27 的機率是 0.0%。JDK 28 preview 的機率大概超過 85%——他們還有 7 個月可以做更多改進。」在一片理性討論聲中，也有不少開發者選擇單純向 Valhalla 團隊表達敬意：「向整個 JDK 團隊及所有直接或間接參與 Valhalla 專案的人致敬，慢慢來，我們知道最終成果會很棒！」

社群反應

本報觀點：Project Valhalla 的進展節奏一向緩慢卻扎實，這次 PR 提交是技術層面的重大訊號，但距離正式 preview 仍有一段路要走。對 Java 生態圈而言，value types 一旦落地，將從根本上改變高效能 Java 程式的設計方式——這是值得等待的變革，只是「等待」二字，Java 社群早已練就了十足的耐心。← 藏鏡人批：十年磨一劍，Java 社群的耐心大概是所有語言社群裡最強的——畢竟已經等過 Lambda、Stream、Records，再等 value types 不算什麼。

2. [科技] JEP 草案：強化 Local Variable 宣告，解構賦值有望進入 Java

• 作者：ihatebeinganonymous | 87↑ | 43 則留言

報導

（本報賈新聞／科技組報導）OpenJDK 社群近日流出一份 JEP 草案，正式編號 JEP 8357464，主題是強化 Java 的 local variable 宣告機制。草案提議讓開發者能透過 pattern matching 語法，一次從單一來源值中解構出多個變數，大幅簡化現行需要逐一取值的冗長寫法。消息在 Reddit r/java 社群引發熱烈討論，短時間內累積 87 票支持、43 則留言。

以往 Java 開發者若要從物件中取出多層巢狀欄位，必須拆開多行逐層拆解；新草案的目標是讓如下語法成為可能：

Circle(Point(int x, int y), double radius) = c;

一行即可同時取出 x、y、radius 三個變數，概念上與 Python、JavaScript、Rust 等語言的 destructuring assignment 如出一轍，Java 陣營稱之為「資料導向運算（data-oriented computations）」的語法支援。

社群中有人立即整理草案核心，言簡意賅：「增強 local variable 宣告，讓 pattern matching 可以從單一來源值提取多個值。這讓資料導向的運算可以更簡潔地在方法體內表達。」（RabbitDev，35 票）

不過也有開發者認為草案走得不夠遠。留言者 persicsb 指出：「想法不錯，但我希望能進一步延伸。既然方法參數看起來就像 local variables，為何不讓這個語法也能用在方法參數上？」（22 票）語法美觀的爭議也不缺席，DesignerRaccoon7977 直言：「喜歡這個想法，但語法太醜了……我不認為在靜態型別語言裡能用漂亮的語法實作這個功能。」（9 票）

值得注意的是，草案標記為「Preview」特性，意味著若最終進入正式 JDK，開發者初期仍需以 --enable-preview 旗標啟用，且語法仍可能在預覽期間依社群反饋調整。

社群反應

本報觀點：Java 近年透過 pattern matching 系列 JEP 持續補齊函數式語言早已視為常識的功能，此次草案是合理的下一步。語法醜不醜是品味問題，但能不能在一行裡把資料拿乾淨，則是工程生產力的問題。← 藏鏡人批：Kotlin 早就做了，Scala 也做了，Java 的 pattern matching 系列 JEP 像是在用 10 倍的工時補 10 年前的功課。草案尚在早期，能否在 Preview 期間收到足夠的實戰回饋、把語法打磨到位，才是真正的考驗。

3. [產業] OpenJDK 官方內容不夠用？社群呼籲深化 Java 記憶體效能討論

• 作者：（匿名） | 87↑ | 71 則留言

報導

（本報賈新聞／產業組報導）隨著 OpenJDK 旗下多個重磅計畫——Project Valhalla、Project Loom、Project Leyden——逐步推進，Java 在記憶體效率與執行效能方面的潛力持續引發討論。然而，近日一篇在 Reddit r/java 版獲得 87 票支持的貼文卻點出一個現實：OpenJDK 官方在這些技術面向的系統性內容產出，遠不及社群的期待。

發文者認為，當前關於 Java 記憶體效率的討論過於零散，缺乏有條理的官方文章或指引，導致開發者在調優時仍得靠自行摸索。他呼籲 OpenJDK 社群或相關貢獻者能更積極地輸出有深度的技術內容，讓這些改進對普通開發者更加親近。

然而，此文一出卻也引來不少回嗆。留言區高票回應 sarkie 毫不客氣地說：「所以你打算寫這些內容嗎？還是說這篇文章只是呼籲大家去做？我有點搞不清楚這篇的目的。」話語間帶著濃厚的「說的比做的多」質疑，獲得 33 票共鳴。

另一位高票留言者 audioen 則從技術角度剖析：「我覺得大概 100% 的記憶體效率討論都是不夠深入的。很多時候只是因為 Java 預設佔用 25% 的系統 RAM——如果你有 128GB 記憶體，就是 32GB 給了 JVM。其實只要調個 JVM 參數就解決了，不是 Java 本身的問題。」他的說法暗示，部分「Java 記憶體問題」其實是配置問題而非語言缺陷。

在實際工程場景方面，OddEstimate1627 分享了第一線經驗：「我們有好幾個演算法同時有 Java 和 C++ 實作，Java 在吞吐量方面通常旗鼓相當，甚至勝出。記憶體是高一點，但在大多數生產環境中，記憶體不是瓶頸。」對於未來方向，vips7L 則寄望於工具層面的改善：「希望自動堆積大小調整功能快點落地，能消除很多迷思。」

社群反應

本報觀點：這篇貼文本身就是個有趣的縮影——Java 社群對記憶體效能議題確有強烈需求，但「呼籲」與「產出」之間的落差，恰恰也是開源社群長年的老問題。Project Valhalla 帶來的 value type、Project Leyden 的 ahead-of-time 優化，最終都得靠具體的文章、benchmark、實際案例研究才能真正滲入一線開發者的日常。光靠一篇 Reddit 貼文呼籲，恐怕只是在留言串裡多了一波討論，下次有人問「Java 記憶體怎麼用這麼多」時，還是一樣手足無措。← 藏鏡人批：33 票最高的留言是「你自己去寫啊」——這個社群不缺批評，缺的是動手的人。

4. [工具] 純 Java 數值計算函式庫 JNum v0.1 出爐，挑戰 ND4J 的百 MB 重量級地位

• 作者：CutGroundbreaking305 | 71↑ | 39 則留言

報導

（本報賈新聞／工具組報導）一位名為 CH-Abhinav 的開發者近日在 Reddit r/java 社群發表了 JNum v0.1，這是一套純 Java 實作的數值計算函式庫，主打完全拋棄 JNI 與 C++ 後端，改以 JDK 原生的 FFM API（JEP 454）與 Vector API（JEP 537，Project Panama）撐起核心運算能力。消息一出，在社群引發熱烈討論，截至發稿前已獲 71 票支持、39 則留言回響。

JNum 最大的賣點，是以體積輕薄著稱——整包不超過 100KB，相較於 Java 深度學習生態的老牌選手 ND4J 動輒數百 MB 的體積，幾乎可說是「微塵」等級。在效能表現上，作者實測 reduction 操作（sum、max、min）比 ND4J 快約兩倍；1024×1024 的 float 矩陣乘法約耗時 51ms，不過作者坦承目前尚未實作多執行緒或 L1/L2 cache tiling 等進階最佳化，還有相當大的成長空間。此外，由於徹底捨棄 JNI，JNum 對 GraalVM 原生編譯同樣相容，對於追求零依賴原生部署的專案頗具吸引力。

討論串中最受矚目的留言，來自 ND4J 現任維護者 agibsonccc。他以過來人身份回應道：「嗨！我是 ND4J 的維護者。我其實同意你的看法。不是要嗆你，但我們在十幾年前就試過你這個方向了——當時 BLAS 的原生速度是無法迴避的現實。不過時代在變，Vector API 現在提供的東西確實值得重新審視。期待看到你的進展！」（10 票）這段留言被不少人視為本次討論的精華——老前輩不但沒有潑冷水，反而承認 Vector API 帶來了過去不曾有的可能性。← 藏鏡人批：ND4J 維護者親自入場說「我試過，但現在值得重試」，這句話的份量比所有 benchmark 數字加起來都重。

然而社群並非一面倒的叫好。martinhaeusler 提出較為保守的看法：「這是個很酷的想法，但我不確定在保持跨 JVM 和 CPU 架構可攜性的前提下，Java 能下探到多底層。你遲早會撞到需要寫原生程式碼的牆。」（6 票）arkstack 則相對樂觀：「這個方向很值得探索——純 Java 數值計算搭配 FFM + Vector API，正是更多人應該嘗試的。而且 v0.1 就附上了測試和 JMH benchmark，這點很加分。」（5 票）

作者本人在留言中坦承自己仍在學習 JVM 最佳化，誠摯邀請社群協助改進。程式碼已公開於 GitHub：https://github.com/CH-Abhinav/JNum

社群反應

本報觀點：JNum v0.1 更像是一份「概念驗證加上誠意基準測試」的學習型專案，而非立即可取代 ND4J 的生產工具。但它的意義不在於取代，而在於示範——當 FFM API 與 Vector API 成為 JDK 正式規格，純 Java 數值運算究竟能走多遠，這個問題值得整個 Java 生態系認真面對，而不只是留給某一位正在學習 JVM 最佳化的年輕開發者獨自探索。

5. [科技] 2004 年 RuneScape 如何把多人 RPG 塞進 56k 撥接網路

• 作者：jkmonger | 14↑ | 6 則留言

報導

（本報賈新聞／科技組報導）在寬頻尚未普及的 2004 年，一款名為 RuneScape 2 的多人線上角色扮演遊戲，硬是靠著 56k 撥接數據機擠進了全球玩家的電腦——而且跑得有模有樣。近日，技術部落客 jkmonger 從反編譯的 RuneScape 2 客戶端原始碼下手，逐字節解析「往北走一格」這個看似簡單的操作，揭露了開發團隊在極度受限的硬體條件下，如何榨乾每一個位元組的傳輸效率。

56k 數據機的實際下行速率約每秒 5KB，上行更少。Jagex 的工程師面對的不只是頻寬窄，還有平台枷鎖：遊戲以 Java applet 形式跑在瀏覽器沙箱裡，只能用 TCP，連 UDP 都碰不到。伺服器每 600 毫秒執行一個 tick，一口氣處理所有在線玩家的更新，再把結果打包送出。

加密設計上，每個封包的開頭只有一個 opcode byte，卻用 ISAAC stream cipher 加密。封包 body 並未加密，只有 opcode 本身被保護——外界若不知道 opcode 是什麼，就無從解讀後面的 bytes，這是最低成本的防護思路。

「往北走一格」這個動作，最終只需要 7 個 bytes 傳到伺服器。這背後的關鍵是：客戶端只傳路徑的「轉角點」，中間的直線由伺服器自行推算；第一個 waypoint 用絕對座標（2 個 short，共 4 bytes），後續每個 waypoint 只傳相對第一點的 delta，各用 1 個 signed byte 表示 x 和 z，比原本的 short 省下整整一半空間。

更有趣的是防作弊設計：不同版本的客戶端刻意把 packet body 的欄位順序打亂，還對個別 bytes 施以 endian 翻轉、加常數、取負值等變換。這意味著即使有人成功逆向了某個版本，下一版又是另一套規則，維護第三方機器人的成本被大幅墊高。

社群反應

本報觀點：這篇技術考古展示了一個現在幾乎不會再發生的設計場景——當頻寬是真正的稀缺資源時，工程師被迫把每一個 byte 都想清楚。如今雲端、CDN、5G 讓人很少再去計算「一個動作要傳幾個 bytes」，但 RuneScape 2 的這套 7 bytes 走路協議，或許正是提醒我們：所謂的「夠用就好」，在資源充裕的時代可能只是懶得想清楚。← 藏鏡人批：諷刺的是，這篇文章本身被最高票留言批評充滿 LLM 痕跡——技術內容在講節省每個 byte，寫作卻在浪費每個字。

社群溫度計

本日 r/java 其他值得關注的討論：