苦勞德報 for Java — 2026-07-13

2026-07-13

1. [頭版] Java 27 到底有什麼新東西？一場「小而穩」的釋出，把大招留給了 Java 28

• 作者：u/loicmathieu | 73↑ | 15 則留言
• 輔助來源：
  • 原文出處：loicmathieu.fr — Java 27: What's new?

報導

（本報賈新聞／科技組報導）Java 陣營又到了半年一度的盤點時刻。開發者 loicmathieu 在自己的部落格整理了一篇「Java 27 有什麼新東西」，貼上 r/java 後衝到 73 讚、引來 15 則討論。原文寫作當下 Java 27 剛進入 Rampdown Phase One（功能凍結第一階段），全版本一共只收了 9 個 JEP，作者一句話定調：這是一次「小而穩」的釋出，沒有任何重量級特性從 preview 畢業。

先看真的落地、進入 stable 的四項。JEP 523 把 G1 拉上來當所有環境的預設 garbage collector，連過去在低資源機器上習慣用 Serial GC 的場景也一併換掉，理由是效能已經追平。JEP 534 讓 Compact Object Headers 預設開啟，物件標頭從 128 bits 砍到 64 bits，作者引數據說可省下約 22% heap 空間、GC 頻率降約 15%，是這版最有感的效能紅利。安全面則有兩項：JEP 527 為 TLS 1.3 導入 Post-Quantum 混合金鑰交換，把 ML-KEM 與 ECDHE 綁在一起抵禦未來的量子破密；JEP 536 讓 Java Flight Recorder 能在寫入前就用 glob pattern 把參數與環境變數裡的機敏資料遮蔽掉。API 層另有 Math 雙曲函數、String.encodedLength()、BigDecimal.rootn() 與時區偏移格式化等零碎補強。

至於大家最期待的那批，全都還在原地踏步：Lazy Constants（JEP 531，third preview）、Primitive Types in Patterns（JEP 532，第五次 preview）、Structured Concurrency（JEP 533，第七次 preview）、PEM Encodings（JEP 538，third preview），連 Vector API（JEP 537）都已經第十二次 incubator，而且明講要停下來等 Project Valhalla 進到 preview 才動。這也解釋了為什麼作者說「真正的好戲會在 Java 28」。

放進釋出節奏來看，Java 27 是介於 LTS 之間的過渡版——上一個 LTS 是 25、下一個要等 29。它的角色本來就不是端出新語言特性，而是把 G1 預設化、Compact Object Headers 這類「打地基」的東西穩穩收尾。留言區也精準呼應了這個定位：有人直說「Valhalla 在召喚我」，有人卡在只跟 LTS 的公司、得再等 29；而效能派則圍繞 GC 選擇吵成一團，替 G1 為何不換 ZGC 給出了相當務實的答案。本報觀點：Java 27 沒有煙火，但把 heap 省下來、把後量子安全補上、把預設值調到更合理，這種「無聊的可靠」反而是生產環境最想要的釋出。真正該焦慮的不是這版沒大招，而是你的公司到底跟不跟得上這條每半年一班的列車。← 藏鏡人批：Compact Object Headers 這種默默省 heap 的更新，比任何 preview 都更值得你先升上去。

社群反應

2. [技術] Java 21 虛擬執行緒：讓「笨方法」重新變成好方法

• 作者：u/AccomplishedArea4456 | 95↑ | 28 則留言

報導

（本報賈新聞／科技組報導）一段「一個請求配一條執行緒、需要等就直接卡著等」的老派寫法，正在 Java 社群重新翻紅。原 po 在 r/java 指出，Java 21 正式端出的 virtual threads，最有意思的地方不是效能數字，而是它讓最直覺的 thread-per-request 阻塞式模型「重新變得可行」。過去這種寫法的天花板卡在 OS thread 昂貴 — 每條 platform thread 都吃記憶體與排程成本，數量一多就撐不住，於是 I/O-heavy 的服務被迫轉向 reactive／async 那套 callback、非阻塞的寫法來擴展。virtual threads 的成本極低，可以同時開出成千上萬條，等 HTTP、等 DB query、等外部 service 時大量掛著也不痛，等於用「看起來很笨」的同步程式碼，換到過去只有 reactive 才有的擴展性。原 po 也把心得整理成一個 concurrency 範例 repo 分享。

留言區沒有一面倒的歡呼，反而補上了難得的實戰細節。網友 u/Illustrious-Music507 真的跑了實驗：在 Spring Boot 塞一個 200ms 的阻塞式 downstream 呼叫，把並發從 50 掃到 2000。結論很誠實 — 在還沒打滿 thread pool 之前，virtual threads 完全沒差，throughput 一模一樣，「這是大多數服務大多數時候的狀態，值得講清楚」。真正發威是在約 1000 並發時，相對預設 200 條的 Tomcat pool 拿到約 4 倍 throughput，而且延遲貼近 downstream 真實耗時，不會塞進 queue 暴衝。但他也發現，只要手動把 platform pool 開大到對等負載，純 throughput 幾乎打平（差 0.2% 以內）— virtual threads 真正的價值是 operational：不用再依負載手調 pool size，而且每條 thread 實測約 135KB stack，並非傳說的「1MB per thread」。代價則是尖峰記憶體約 2.2 倍，因為每個 in-flight 請求都是真的活著，他建議加 bulkhead／semaphore 防 OOM。

另外多位網友點出兩個要留意的坑。其一是 pinning：多人提到 Java 21 的 synchronized 區塊仍會把 virtual thread 釘在 carrier thread 上，直到 JDK 24（JEP 491）才基本解除，過去「全部改寫成 ReentrantLock」的建議如今大致過時。其二是下游限流的心智轉換 — u/henptk14 提醒，傳統 thread pool 本身就是天然的緩衝閥，換到 virtual threads 後必須自己對 DB 連線、downstream、rate limit 設上限，否則瓶頸只是從 thread 挪到 DB connection pool（實驗裡 Hikari max=10 就直接卡死上限）。本報觀點：virtual threads 不是把 reactive 掃進歷史，而是把「大部分只是在等 I/O」的服務，從被迫學 reactive 的門檻解放出來 — 但它移動天花板、不會移除天花板，限流與資源上限的功課一項都省不掉。← 藏鏡人批：換上 virtual threads 的同一天，記得順手替 DB pool 和 downstream 設好上限，不然瓶頸只是搬家。

社群反應

3. [產業] 自己養一套 JVM 划算嗎？大廠可以，但你多半不必

• 作者：u/TheoreticalDummy | 91↑ | 89 則留言

報導

（本報賈新聞／產業組報導）r/java 一則貼文丟出了不少企業架構會議上暗自出現過的問題：一家公司自己維護一套 in-house 的 JVM，到底實不實際？跟直接買授權、或改用非 GPL 的 JDK 實作相比，這不是要燒掉一大筆資源嗎？原 po 只留了標題、沒有內文，卻在一天內炸出 89 則留言，社群把這件事的來龍去脈拆得相當清楚。

第一個要澄清的，是大家嘴上講的「自己的 JVM」多半名不副實。多位開發者指出，Amazon 的 Corretto 其實是 HotSpot／OpenJDK 的 fork，只是打上一小撮 patch、外加把後續版本的修正 backport 回來，Amazon 做的原創工作也多半 upstream 回 OpenJDK，屬於「貼很近的分支」，離「自己一套實作」差得遠。真正從零做 clean room implementation 的門檻高到嚇人 —— 不只要跑完某個版本的全部 bytecode，還得把標準函式庫中大量直接呼叫 JVM 內部 API 的部分（例如 FFM）一起實作，工程量大部分卡在後者。有人補一句到位：寫一個 JVM 不難，寫一個「效能打得贏 OpenJDK」的 JVM 才是天文數字級的難。

那大廠為什麼還是做了？留言普遍認為這類案例幾乎都是歷史因素。有人點名 SAP：Java 還沒開源、還是 interpreted language 的年代，做系統要撐 20 年以上、又不信任 vendor 不會中途砍產品，手上預算又夠，那時寫個直譯器避開 vendor risk 是合理的；一旦養出來、只需支援自家程式碼，它就會長出各種怪癖，遷移到別的 JVM 反而變高風險，於是「繼續養它」比「搬走」更便宜。IBM 的 J9 則是另一種邏輯 —— 動機跟硬體綁定（他們自己的機器），而不是為了省授權費。

至於授權，留言把最大的迷思也戳破了：OpenJDK 走的 GPL 帶有 Classpath Exception，除非你去改 JDK 本身，否則你的程式碼不會被傳染成 GPL。有資深開發者算了帳：自己 build OpenJDK 本身沒什麼問題，但要撐正式生產環境，光維持 build 就得養 2 到 5 人，要修 bug、backport、加功能，人力上看 10 到 15 人；相較之下，多數公司只要花一次性的法務費用確認 GPL 用法沒問題就好。本報觀點：這題的答案幾乎寫在帳單上 —— 自維 JVM 是 hyperscaler 級的歷史包袱與規模生意，對絕大多數團隊，直接抓免費的 Temurin、Corretto 這類發行版才是划算解，會冒出「自己做一套」念頭的，多半是把 fork 一個 repo 誤當成造引擎的自我膨脹。← 藏鏡人批：先分清楚你要的是「fork 打幾個 patch」還是「clean room 造引擎」，99% 的人講的是前者。

社群反應

4. [工具] 嫌 Maven 太肥，他真的動手做了一個：Curie 掀 Java 建構工具極簡之爭

• 作者：u/sentinel04 | 0↑ | 51 則留言
• 輔助來源：
  • Simple Build System 討論串（0↑／22 則）

報導

（本報賈新聞／工具組報導）一年前，r/java 上有人拋出「Java 到底需不需要一個新的建構工具」的辯論，多數人吵完就散了；u/sentinel04 卻把這個念頭放在心上，這回真的動手做了一個，取名 Curie，端上檯面請社群公審。他開宗明義說得很誠實：「還很早期、也很多 bug，這是概念驗證（proof-of-concept），不是叫你明天就丟進 production 的東西。」目的只是想試探——社群對這種工具到底有沒有胃口。

Curie 主打的是把 Cargo（Rust 的建構工具）那套體驗搬進 Java。它用一份精簡的 Curie.toml 取代動輒上百行的 pom.xml；本身以 Rust 寫成，所以啟動即時、沒有常駐 daemon。過去要靠 plugin 一個一個外掛的常見功能，Curie 選擇直接內建：compile／test／package、程式碼格式化（Java 與 Kotlin 都吃）、Docker image 產生、相依套件弱點掃描、Maven 發布，還有預設就 byte-identical 的可重現建構（reproducible build）。一言以蔽之，作者要對付的正是那串老抱怨——plugin fatigue 與 XML／DSL 的無限膨脹。

有趣的是，同一時間 r/java 另一頭，u/bowbahdoe 丟出一篇標題只有「Simple Build System」的貼文，連結到他自己用純 Java 程式碼寫的建構腳本，走的是完全相反的極簡路線——不要 DSL、不要設定檔，建構邏輯就是 Java code 本身。兩篇分數都掛零、卻各自炸出五十一則與二十二則留言，正是典型的「討論度大於票數」題：Java 社群對「建構工具能不能更簡單」這股情緒，顯然壓抑很久了。

留言區的攻防很精采。正面派如 u/TheStrangeDarkOne 認為這是「近期比較像樣的新建構工具嘗試」，最期待的是原生多模組（multi-module）支援；u/Kungpost 這種 Cargo 愛好者則直接表示有興趣。反面火力也不小：資深開發者 u/khmarbaise 列出一長串 Maven 早已解決、Curie 卻還缺的功能——多模組部署、Spring Boot fat-jar、JaCoCo、整合測試、resource filtering、IDE 支援等，句句往生態相容性的痛點戳。u/cleverfoos 則從立場質疑：「可惜它不是用 Java 寫的，這樣就沒能替 JVM 當個好大使。」更別提那句幾乎必然出現的靈魂拷問——u/jivedudebe 搬出那張「本來有 12 個標準，於是我們做了第 13 個」的迷因，直接把 NIH（Not Invented Here）的帽子扣上。就連對面 Simple Build System 那篇，最高票留言也只有冷冷一個字：「Why?」倒是 u/nnomae 一針見血點出全場氣氛：「沒什麼比這更能總結 Java 的心態了——有人想把事情做簡單，底下留言卻清一色是『為什麼不搞得更複雜一點？』」

本報觀點：Curie 的清單很誘人，但 u/brunocborges 那句「除了開發體驗，你這工具比 Maven 到底多做了什麼、或哪裡做得更好？」才是它必須回答的關卡。Java 建構工具的難，從來不在「能不能更簡單」，而在既有生態（IDE、企業內部 Maven mirror、無數 plugin）的重力太大——極簡的代價往往是相容性歸零。Curie 選 Rust 換來零啟動延遲，卻也親手切斷了「用 Java 寫 plugin」這條 Java 社群最熟的路。這場爭論真正有價值的不是誰勝出，而是它逼著大家重新問一次：我們對 build tool 的複雜度，到底是被逼的，還是習慣的？← 藏鏡人批：討論度輾壓票數，正說明大家嘴上嫌、手上還是離不開 Maven。

社群反應

5. [產業] 非 Java 團隊該為了微服務引入 Java 嗎？技術選型的拉鋸戰

• 作者：u/ArtisticRevenue379 | 37↑ | 72 則留言

報導

（本報賈新聞／產業組報導）一名開發者在 r/java 拋出一個看似技術、實則管理的難題：他的團隊手上已經有 Python、Go 與 Dart 三種語言的服務，現在因為聽說「Java 這些年進步很多、生態系又龐大」，正在考慮把新的微服務改用 Java / Spring 來寫。但他心裡有個坎過不去——當初團隊選 Go 是因為「你就直接把事情做出來」，寫起來直觀；換到 Spring 卻感覺「不太像在寫程式」，而是要先搞懂一堆 annotation、還要摸清 Spring 到底期待你怎麼用它。他想問：是自己的錯覺，還是 Java / Spring 真的自帶一條特殊的學習曲線？

七十二則留言幾乎一面倒，但方向不是「Java 好不好」，而是「你有沒有好理由多養一種語言」。最高票的 u/NoForm5443 直接點題：沒有夠強的理由，別往技術棧裡再塞新語言；他補充 Java 本身的學習曲線只比 Python 陡一點，真正難的是 Spring 這個「巨無霸框架」，若真要入門 Java，Micronaut 這類較輕的框架反而好上手。u/vmcrash 講得更狠——在一個 Python/Go/Dart 團隊裡他絕不會建議加 Java/Spring，「與其加第四種語言，我寧可想辦法砍掉一種，比如 Python」。有人搬出 Choose Boring Technology 的老道理，也有人從招募角度算帳：同時懂 Python、Go、Dart 的人本來就不好找，再加一條「要會 Java」，只會讓你更難快速補到即戰力。

技術面的討論同樣精采。多位留言者證實原 po 對 Spring 的直覺沒錯：Spring 的 annotation 與 autowiring 是「convention over configuration」的極致，好處是熟手能飛快 scaffold、在服務之間無痛跳轉，壞處是對新手而言 wiring 全藏在黑魔法裡，debug 時難以追蹤控制流（有人建議靠 IntelliJ 的 Spring plugin 輔助）。因此不少人給出折衷路線：真要進 JVM，不一定得從 Spring 起手——Quarkus、Micronaut 這類 annotation 驅動但偏 compile-time、更可預測的框架，或 Javalin、Helidon SE 這種近乎零 annotation、寫起來像 Go 的 Gin 或 Node 的 Express 的輕量選擇，甚至直接用 JDK 內建的 jdk.httpserver 手刻一個 CRUD 服務，都比一頭栽進 Spring 溫和。至於啟動時間與記憶體，有人點出 Spring 的 autowiring「慢得驚人」、codebase 一大就更難導航，若在意低記憶體與生產力，Go 依然更合身；Java 的優勢反而在長時間運行、追求最大 throughput 的成熟平台特性上。連 Spring 官方團隊的第一位 developer advocate、starbuxman（Josh Long）都現身留言，坦承自己「立場超級偏頗」，卻同樣勸退：微服務理論上可以各用各的語言、壞了就丟掉重寫，但實務上服務一多，security、observability、routing、load balancing 這些 cross-cutting concerns 每種語言都得重解一次，成本只會複利式累積——「加 Java 之前先砍掉一個東西，能標準化就標準化，less is more」。

本報觀點：這題表面在問語言，底層問的其實是「一致性」值多少錢。微服務允許 polyglot（多語言）沒錯，但每多一種語言就多一份認知負荷、多一套部署工具、多一組沒人想接手的孤兒服務——這些隱性成本往往在「當初寫的人離職之後」才一次結清。Java 21 之後語言本身確實好用了，Quarkus、Micronaut 也讓 JVM 微服務不再等於「等它慢慢開機」，就連「Spring 黑魔法沒人會 debug」這個老問題，都有留言者半開玩笑說「現在任何一個像樣的 AI 就是那個懂 Spring 的人」。技術門檻確實在降。但這些都改變不了核心判準：除非你能講出一個具體到不能再具體的理由（不是「我聽說 Java 效率高」，而是「我需要 structured concurrency」或「有個 Java 函式庫剛好完美解決我的問題」），否則最好的語言永遠是團隊已經精通的那一種。想試？照留言的建議，先用 plain Java 手刻一個小服務 benchmark 一下再說，別把整個團隊押上去。← 藏鏡人批：連 Spring 官方 advocate 都勸你先砍一種語言，這個 signal 很難得。

社群反應

社群溫度計