苦勞德報 for Java 生態 — 2026-06-11

2026-06-11

1. [頭版] JEP 401 值類別準備合併進 JDK 28，Valhalla 等了十年終於要上桌

• 作者：Jab125RedditAlt | 126↑ | 57 則留言

報導

（本報賈新聞／科技組報導）等了十年、被社群調侃成迷因的 Project Valhalla，總算走到實際併入主線的一步。OpenJDK 郵件論壇本週公告，JEP 401「Value Classes and Objects」即將合併進 JDK 28，正式宣告 Valhalla 的第一塊核心拼圖落地。消息一出，r/java 立刻被洗版，原 po Jab125RedditAlt 把 jdk-dev mailing list 的公告直接搬上看板，貼文一夜衝上 126 分、57 則留言。

接續上一期苦勞德報 for Java（2026-06-01）報導的 Valhalla 值類別 PR 提交，這一回從「PR 進到 review queue」推進到「準備併入下一個開發週期的 JDK 28」，時序進展明確。根據公告，這次變更規模驚人 —— 2,800 個 commit、1,800 個檔案異動，內容涵蓋 JVM 內部對 identity 與 value 兩種物件模型的雙軌支援、新增 value 修飾詞、以及大量 core library 的內部改寫，是近十年來 JVM 規格層面最大的單一變更之一。社群網友 SalutLesAmies 直接引用公告原文「This is an extremely large change」並補刀：「2,800 個 commit、1,800 個檔案，這確實叫『超大』。」

值類別的目的，是讓 Java 終於能像 record 一樣寫出「沒有 identity、只看內容相等」的物件，讓 JVM 在底層可以攤平記憶體配置、消除 boxing 開銷，未來 Generic Specialization、Universal Generics 等後續 JEP 才能接著推進。不過社群也提醒要冷靜：JDK 28 多半是以 preview 形式進來，要真正成熟還得等下一個版本，而生態系（framework、ORM、序列化庫）要全面吃到 value class 的紅利，更是長期工程。

本報觀點：JEP 401 落地不代表 Valhalla 結束，反而才是真正進入生態系驗證期，函式庫、framework、ORM 全要重新審視自己的物件模型；Java 開發者那件「Valhalla When」T-shirt，從今年起終於可以洗了 —— 雖然社群網友 IncredibleReferencer 嘴硬地說：「我才不會把我的 Valhalla When T-shirt 丟掉，你逼我也沒用。」這場馬拉松終於跑進體育場，但離終點線還有最後一圈。← 藏鏡人批：等了十年的迷因 T-shirt，終於可以從衣櫃裡爬出來進 JDK。

社群反應

2. [產業] Eclipse 還有人用嗎？Java IDE 世代戰再起

• 作者：RamaRao143 | 155↑ | 189 則留言

報導

（本報賈新聞／產業組報導）r/java 一則簡短到不能再簡短的提問「Eclipse 還有人在用嗎？」，意外在 24 小時內衝出 155 分、累積 189 則留言，掀起 Java 開發者圈的世代戰。樓主 RamaRao143 只丟出一句疑問，留言區卻像被點燃的火藥庫，從「我撐了好幾年終於投降轉 IntelliJ」、到「Eclipse 我至死不渝」、再到「NetBeans 才是真神」，幾派人馬同台輪番開講。

最高票留言來自 u/PhilosopherNo2640（217↑），他坦承自己「抗拒了很久，大約一年前終於換成 IntelliJ，現在習慣後再也回不去了」。第二高票的 u/Far_Note6719（134↑）說得更直接：「Eclipse 看起來、用起來就像來自過去的軟體，光是那個外觀就讓我覺得自己又老又難過。」這類「終於投降派」的敘事撐起整個討論串的主軸 — IntelliJ 在 Java IDE 戰場已成默認共識，而轉換成本是大家共同的痛。

但 Eclipse 並非全無支持者。u/aoeudhtns（36↑）寫了長文歷數 Eclipse 留人的理由：incremental compilation 表現優異、multi-module 處理嚴謹（他指 IntelliJ 在多 project 並存時會讓所有 module 互相吃到依賴，反而容易讓 build 階段炸鍋）、native UI 的速度與延遲感、以及 perspective 切換工作環境的設計。u/Mechanical-pasta（60↑）則點名仍在用 Spring 官方魔改版 STS（Spring Tools Suite）。更冷門的是 u/euclid15（34↑）跳出來宣告：「NetBeans 才是最強的 Java IDE，我們這群識貨的還有十幾個人。」

值得注意的是，留言中陸續出現 VSCode 作為第三勢力的提及 — u/Degerada（53↑）指出「大宗是 IntelliJ，VSCode 的比例正在快速上升」，暗示新一代開發者根本不從 Eclipse vs IntelliJ 二選一出發，而是直接拿 VSCode 開 Java。

不過這場「逃離 Eclipse」的敘事，有個社群常被忽略的諷刺事實 — VSCode 跑 Java 是靠微軟維護的 vscode-java 套件，底層直接接 Eclipse 自己的 eclipse.jdt.ls（Eclipse JDT Language Server）。換句話說，那群「轉 VSCode 逃離 Eclipse」的開發者，code intelligence、refactor、incremental compile 的引擎其實還是 Eclipse JDT 沒換過。Eclipse 沒有死，它只是從 IDE 外殼變成了 language server 引擎，被 VSCode、Neovim、Emacs 透過 LSP 一路繼承下去。

本報觀點：Java IDE 的版圖確實在洗牌，但這場討論真正的看點不是誰會贏，而是 Eclipse 死忠派與「被職場慣性綁住」的開發者之間，那種混雜著懷舊、肌肉記憶與不想重學 hotkey 的複雜情緒 — 換 IDE 從來就不是純技術選擇，是工作流的整體搬家。← 藏鏡人批：hotkey 肌肉記憶的告別式，比舊愛還難忘 — 分手了，但前任還在你電腦裡跑。就像世紀帝國 II 黑暗時代開局，手指 30 秒內自動敲出 hccc（H 選鎮中心、CCC 連生三隻村民把開局人口上限填滿），即使新版本把整套 hotkey 全換了，老玩家照敲不誤。換 IDE 是身體在等大腦補課。

社群反應

3. [產業] 如果 Oracle 倒了，Java 會變成什麼樣？r/java 開沙盤推演

• 作者：bowbahdoe | 25↑ | 35 則留言

報導

（本報賈新聞／產業組報導）r/java 版友 bowbahdoe 拋出一個少見的「思想實驗」題目：如果 Oracle 倒了，Java 生態會怎麼走？他自陳這原本想寫成 blog，但「我也沒什麼聰明話可說，只想讓大家知道現在發生什麼事」，乾脆貼到版上開放討論。

OP 把推演的前提一條一條鋪開：Oracle 為了蓋資料中心扛了一大筆債，而那些資料中心的潛在客戶其實只有 OpenAI 與 Anthropic 兩家；資料中心要等到上線、有客戶實際付帳才會回收，假如 OpenAI 沒辦法成長到「Google、Amazon、Microsoft 加起來」那種等級，根本付不出帳單。對 Oracle 而言，這是公司層級的存亡威脅。問題是 — Oracle 同時握有 Java 商標，並雇用了多數 OpenJDK 核心開發者，「Oracle 倒掉、或只是把剩下的資金抽離 Java，對整個語言的發展都會有影響」。

他特別強調這不是「總會有人接手」就能輕鬆帶過的事，並把球丟向業界：如果在場有人任職於不會在這場景倒掉的大公司，是否該提前準備接收商標與人才？真到了資產拍賣那一步，是不是該成立 non-profit 來接？

底下推演沒有走向恐慌，反而長出兩條主軸。一派把這當成生態解放的契機，最高票留言（30↑）的 predator 直言：「也許這正是業界需要的那一推，把 Java 移到一個真正的 foundation 底下。不管最後是像 Rust Foundation 的 501(c)6 或像 Zig Foundation 的 501(c)3，任何模式都比現在『一家大邪惡公司獨佔』要好。」這呼應了長年來對 OpenJDK 治理、TCK 授權集中在 Oracle 手上的不滿 — Spring 生態、JetBrains、各家 JDK distribution（Amazon Corretto、Azul、Red Hat 等）雖然能合作 OpenJDK，但 Java SE 商標與 TCK 認證仍是 Oracle 的牌。

另一派則覺得 OP 整個前提有問題。23↑ 的 sweating_teflon 認為這是想太多：「Oracle 的本業是連撒旦都會驕傲的那種永久制度型合約，加上一卡車內部律師，他們只是在 AI 賭桌上對沖。真的崩了，基礎設施會賣給其他玩家或對北美市場有興趣的國家級買家。」也有人點出 Oracle 授權營收的厚度（「你不知道全世界付了多少 Oracle 授權費」）、加上美國政府不會放任「too big to fail」的 Java 生態崩解。

第三派則延續決定論的樂觀 — 22↑ 的 RoomyRoots 直接舉 OpenJDK 自己的歷史為證：「就跟其他專案一樣，有興趣維持它活下去的人會用上班時間或私人時間繼續貢獻。」也有版友把希望寄託在具體買家：當年 Sun 賣身時就希望由 IBM 接手而非 Oracle，因為 IBM 比較在意技術本身，現在若重來一次，IBM 仍是首選。也有人半開玩笑說「我只希望我們至少先拿到 Valhalla」，把焦點拉回未完成的語言特性。

本報觀點：這場沙盤推演本身比結論有趣 — 它讓平常被視為理所當然的「商標歸屬、TCK 授權、核心 commit 權」攤在陽光下，提醒社群這些治理基礎並非從天而降。即使最後 Oracle 沒倒，光是業界願意公開盤點「如果倒了該怎麼辦」，本身就是 Java 治理討論難得的一次熱身。← 藏鏡人批：治理基礎攤在陽光下，才發現腳沒幾條。

社群反應

4. [科技] Java 直闖 GPU Tensor Cores！Project Babylon 端出 HAT，純 Java code 跑出 7.3 TFLOP/s

• 作者：JMasterRedBlaze | 21↑ | 2 則留言

報導

（本報賈新聞／科技組報導）OpenJDK Project Babylon 團隊的 Juan Fumero 本月發表文章〈Exploiting GPU Tensor Cores from Java using Babylon〉，示範如何不寫 CUDA、不靠 JNI、純粹用 Java 程式碼就把 NVIDIA GPU 上的 Tensor Cores 操起來跑矩陣乘法，在 NVIDIA A10 上實測達到 7.3 TFLOP/s，與手寫 CUDA C++ WMMA 版本幾乎打平，並把樸素 matrix multiplication 的 240 GFLOP/s 一口氣推高約 30 倍。這篇文章在 r/java 上線後被視為 Java AI 路線上的一個重要里程碑。

技術上，這條路靠的是兩塊新基礎建設。一塊是 Project Babylon 推進中的 code reflection API — Java 編譯器把 method body 不只編成 bytecode，還同時產出可在執行期遍歷與改寫的 code model，等於讓 Java 也能像 expression tree 那樣「拿到自己的程式長相」。另一塊是 HAT（Heterogeneous Accelerator Toolkit）— 一套架在 code reflection 上的平行框架，把 Java code model 翻譯成 CUDA 或 OpenCL kernel source 後丟給 driver 編譯執行。這次新加的是 tensor-aware API，讓開發者在 Java 端宣告 tensor 形狀與 MMA 操作，HAT 編譯期再決定要 lower 成 NVIDIA wmma::load_matrix_sync 這類 intrinsic，或是在沒有 tensor 硬體的平台（如 Apple M4 走 OpenCL 1.2）改 lower 成 explicit tile loop。同一份 Java source 因此能在 CUDA 與 OpenCL 兩個 backend 之間搬遷，在 M4 Max 上經 group size 與 tile size 微調後，仍可比樸素版本快 8 倍。

與 TornadoVM 等既有方案相比，路線差異在於「靠不靠 OpenJDK 的語言基礎建設」。TornadoVM 走的是 Graal-based JIT 改寫路線，自己在 IR 層做 GPU lowering；Babylon/HAT 則直接用 OpenJDK 主線正在推的 code reflection 作為 source-of-truth，等於把 GPU 程式設計變成 OpenJDK 語言層的一級公民，未來與 Valhalla、Panama 的整合動線會更直接。Fumero 在文末也提醒，HAT 與 tensor API 的最終整合「仍在討論中」，今天看到的是「能跑、效能對齊 CUDA」的工程驗證，不是 production-ready 的承諾。文章另附 alignment 與 tile size 調參細節，包括 F16Array 補 28 bytes padding 才能滿足 load_matrix_sync 的 256-bit 對齊要求，是這類 Java-to-GPU 工程裡常見的暗坑示範。

本報觀點：這篇東西出現在 Java AI 話題正熱的時間點絕非偶然。LLM inference 八成以上的算力吃在 MMA 上，Java 圈若要在 AI 工作負載上不靠 Python 中介，這層 Tensor Cores 直連就是必過的關。Babylon + HAT 把這件事從「Graal 內部魔法」拉到「OpenJDK 主線語言能力」的位置，路雖然還長，但門終於開了。← 藏鏡人批：Java AI 終於繞過 Python 中介這道牆，還沒到家，門開了。

相關背景／前情提要

5. [科技] Java 8 到 25 LTS 大事記一張圖，作者：別再說 Java 沒進步

• 作者：dxplq876 | 51↑ | 5 則留言

報導

（本報賈新聞／科技組報導）r/java 出現一張被熱議的整理圖，作者 dxplq876 把 Java 從 8 一路到 25 的歷代 LTS（11、17、21、25）主要變化，按 Language、Standard Library、JVM 三大類彙整成單頁速查。他在貼文裡笑說「找了很久都沒看到滿意的，乾脆自己（在 AI 幫忙下）做一張」，意外戳中社群長年痛點：很多開發者其實還卡在 Java 8，對後面十多年到底加了什麼幾乎沒概念。

從 Language 端看，Java 11 把 lambda 參數列也能用 var、Java 17 端出 sealed classes 與 records（後者讓「寫個資料類別還要 50 行 getter/setter」的時代正式結束），Java 21 則把 pattern matching for switch、record patterns 收尾轉正，配上文字區塊（text blocks）和 switch expression，整體寫法已經跟 Java 8 完全不同個世代。Standard Library 端，HTTP Client（11）、Stream.toList()（16）、Sequenced Collections（21）、以及社群最在意的 Foreign Function & Memory API（25 正式版）逐步補齊，讓 Java 不再需要靠 JNI 或第三方 lib 才能跨語言互通。

JVM 這條線變化更猛：ZGC（11 experimental、15 production）把 GC pause 壓到次毫秒等級，而 Java 21 的 virtual threads（Project Loom）與 structured concurrency 則是直接改寫高併發伺服器的寫法 — 過去 reactive 那套為了榨乾 thread 而扭曲程式碼，virtual threads 出來後「同步寫、底層自動 park」變得可行，傳統 thread-per-request 重新有了競爭力。對仍卡在 Java 8 的工程師來說，這張圖的意義不只是「炫耀新功能」，而是提醒：升級路線早已不是「升個 9 就要再升 11」這種痛苦短週期，11 → 17 → 21 → 25 都是 LTS，每跳一階都有實打實的語法簡化與執行期紅利可拿；繼續綁 Java 8，等於主動放棄十年份的免費改善。

留言區補上一個重要勘誤 — 圖中把 FFM API 放在 JDK 21，但實際上 JEP 454 在 JDK 22 才以 final 形式出現，正式版要到 JDK 25 才落地，21 那時還是 incubator。本報觀點：圖會有小錯，但「Java 早就不是你印象中的 Java」這個訊號，比任何 release note 都更有說服力。← 藏鏡人批：升級這件事最大的阻力，從來不是技術，是「我以為它沒變」。

社群反應

6. [工具] 三年 Spring Boot 線上實戰：四個反覆造成事故的行為與對策

• 作者：Capable-Morning-9518 | 96↑ | 9 則留言

報導

（本報賈新聞／工具組報導）r/SpringBoot 6 月 8 日出現一篇實戰回顧，OP Capable-Morning-9518 自述三年在不同團隊看過的線上事故，整理出四個教學文章幾乎不會提、卻反覆讓系統翻車的 Spring Boot 行為，並附上各自的處置方向。

第一坑是 HikariCP 預設連線池只有 10 條。OP 指出，對多數實際 workload 來說這個數字偏低，症狀偏偏長得跟資料庫出問題一模一樣 — latency 攀升、request timeout，但 DB 本身健康得很，元兇其實是 pool 已滿。建議依實際併發量調整 spring.datasource.hikari.maximum-pool-size，並把 pool metrics 透過 Actuator 外露，事故來臨前就能看到 pending threads。

第二坑是 @Transactional 對 checked exception 預設不會 rollback。Spring 只在 RuntimeException 子類被丟出時才回滾，checked exception 飄出 @Transactional 方法反而會把交易 commit 掉 — 資料一致性默默崩壞、log 連個錯都沒有。OP 給的處方是該回滾就明寫 @Transactional(rollbackFor = Exception.class)，否則就要對自己方法會丟哪些例外清楚到骨子裡。

第三坑是 self-invocation 直接繞過 proxy。同一個 class 內某個方法呼叫另一個 @Transactional 方法時，那個 annotation 形同不存在 — Spring proxy 根本沒介入，沒錯、沒警告，就是沒有交易管理。OP 強調這在文件裡寫得清清楚楚，卻常常逃過 code review，連資深工程師都會中招。

第四坑是 GC 壓力長得不像 GC 壓力。Latency 變差、CPU 攀升、沒錯誤訊息，JVM 其實正花越來越多時間做 GC、暫停 thread。最慘的版本是在 Docker container 裡跑卻沒設 -XX:MaxRAM 或 -XX:MaxRAMPercentage，JVM 拿宿主機記憶體去算 heap、結果 container 被 OOMKilled，連 stack trace 都沒留下，工程師花一整晚追根本不存在的 application error。

本報觀點：四個坑共同點是「症狀看起來在別處」 — DB 慢、CPU 高、資料怪怪的，真兇卻在框架預設值或 JVM 設定。Observability（Actuator metrics、container-aware JVM flags）是這類隱性事故的第一道防線。← 藏鏡人批：症狀看似在 DB、CPU、應用層，真兇全在預設值。

社群反應

7. [工具] CMP 跨平台 navigation bar 套件登場！Android 走 Material 3、iOS 套 Liquid Glass 一次到位

• 作者：n_droid_09 | 58↑ | 6 則留言

報導

（本報賈新聞／工具組報導）Compose Multiplatform（CMP）讓開發者能用 Kotlin 一份程式碼同時跑 Android 與 iOS，但「平台原生感」一直是它最被詬病的痛點 — CMP 預設的元件畫面在 iOS 上看起來總是「有點像但不太對」，導航列尤其明顯。r/Kotlin 用戶 n_droid_09 不忍受了，決定自己動手做一個叫做 AdaptiveNavigationBar 的套件，把這個缺口補起來。

作者表示，他自己正在用 CMP 寫一支 app，希望兩邊的導航列都長得像「該平台原本就該長的樣子」。在 iOS 26 上，Apple 推出的全新材質 Liquid Glass 帶來懸浮、毛玻璃般的導航列視覺，是當下 iOS 體驗的招牌之一；而 Android 這邊的標準則早已是 Material 3 的 NavigationBar。CMP 內建元件兩邊都無法精準對齊，他乾脆把自己刻出來的方案抽成 library 開源。

套件以「一份共用 API、底層分流到原生實作」為訴求：Android 端走 Material 3 NavigationBar，iOS 端則套上 Liquid Glass 懸浮列，並附帶 iOS 的 FAB 支援、SF Symbols 圖示整合，以及 Android 端的 DrawableResource 銜接。對 KMP／CMP 開發者來說，這正好填補了「平台原生導航列」這塊長期空白。本報觀點：CMP 生態最缺的從來不是新框架，而是這種「把每個平台的當代設計語言收齊」的小工具 — 願意花力氣把 iOS 26 的 Liquid Glass 拉進來，這份誠意值得記上一筆。← 藏鏡人批：CMP 真正缺的，是有人願意逐個平台補完設計語言。

社群反應

8. [工具] Kotlin 開發者推 kexpresso DSL：讓 regex 一週後還看得懂

• 作者：Emotional-Magician87 | 19↑ | 11 則留言

報導

（本報賈新聞／工具組報導）Kotlin 社群有作者把 kexpresso 0.8.0 推上 Maven Central，宣稱要解決一個老問題 — regex 寫完一週後連自己都看不懂。其核心想法是用 fluent DSL 包裝 kotlin.text.Regex，把符號海換成可讀的方法鏈，例如 email 的驗證從一串 [a-zA-Z0-9._%+-]+@... 的字符類別，改寫成 kexpresso { startOfText(); email(); endOfText() } 這種一眼就能讀完的結構。作者強調 DSL 在建構時就編譯成標準 Regex，比對時 0% overhead，並附上 describe() 解釋既有 pattern、analyze() 偵測 ReDoS 風險、examples() 生成 fixture 等四項配套，全套支援 KMP 多平台目標。

不過社群留言區火力不小。最高分留言抓著作者自己 demo 的 email() helper 不放，直接列出一打 RFC 合法但被擋下的 email 樣本（含引號、IPv6 字面位址、emoji），順手吐槽「AI-speak 痕跡明顯到很懶」；第二高分留言則更根本地反問 — 既然連 helper 內部都寫死 raw regex，那 DSL 的價值是不是只剩聲明、不剩執行？為什麼不直接寫 regex？這個反問把整個討論的張力推到了高峰：DSL 是真的把心智負擔搬走了，還是只是把它從 regex 語法搬到了另一套要學的 API？← 藏鏡人批：用招牌 demo 反打作者，是社群的傳統美德。

社群反應

社群溫度計

下列貼文未獨立成報，列出供讀者快速掃描本期 Java 生態其他熱點。