一個預設值先被換掉了：JDK 27 的升級，是一場無聲的介面設計

2026 年 9 月 15 日，Oracle 正式發布 JDK 27，對應 JSR 402，作為 Java SE 27 的參考實現。多數人看到的新聞句式是「九項 JEP、四項預覽、一項孵化器」，熱鬧但抽象。真正值得停下來看的，是其中幾項「預設行為變更」：開發者什麼都不改，只把版本號往上調一級，行為就變好了。

從設計的角度，這是很少被討論的一種介面設計。大多數產品的介面是畫面，按鈕、選單、配色；而一個程式語言平臺的介面，是它的預設值。預設值決定了大多數人「不假思索」得到的世界，就像一個 app 的初始字級、一支手機的預設鈴聲。JDK 27 這次做的，是把幾個存在了十幾年的預設值悄悄換掉，而且換得幾乎沒有介面上的痕跡。

從 96 位到 64 位：一個看不見的圓角

先看最具體的一項。JEP 534 把緊湊物件頭（Compact Object Headers）設為預設。

在 64 位 JVM 上，傳統的物件布局是 Mark Word 佔 64 位、Klass Pointer 佔 64 位，物件頭合計 96 位，約 12 位元組。加上對齊填充，一個最簡單的 new Object() 實際佔 16 位元組。JDK 27 把 Klass Pointer 壓縮到 32 位，物件頭降到 64 位。

這件事對使用者完全不可見。沒有新的語法、沒有新的 API、沒有任何編譯警告。它像產品設計裡把一個塑膠件的壁厚從 2.5 公釐減到 2.0 公釐：外觀尺寸不變，重量與材料成本默默下降。在大量小物件堆積的服務裡，整個 heap 的footprint 會同步縮小，等於把記憶體這個「材料」用得更省。

這種設計的美感在於節制。它沒有發明新東西讓你學，只是把一個 1990 年代延續下來的內部結構重新量了一次尺寸，然後把省下來的空間還給使用者。好的預設值設計從來不需要說明書。

G1 成為所有環境的預設：把選擇收走，也是一種設計

JEP 523 是另一項預設變更，規模更大：G1 垃圾回收器成為所有環境的預設 GC，不再區分伺服器與受限環境。

背景值得回顧。從 JDK 9 開始，G1 已經是伺服器環境的預設；但在小容器、嵌入式裝置或命令列工具這類記憶體受限的場景，JVM 仍會退回 Serial GC。Serial GC 單線路回收，啟動快，但一旦資料量上來，Full GC 的長時間停頓會讓人以為是自己的程式碼出了問題。很多除錯時間，其實浪費在一個錯誤的預設上。

Oracle 在 JEP 裡給出的理由相當具體：G1 的最大吞吐量已接近 Serial，老年代走增量回收所以延遲本來就更好，原生記憶體佔用降到相當水準，小堆場景的啟動開銷也不再明顯。換句話說，當兩個選項在各項指標上已經追平，留著那個分支的預設，只剩下讓人選錯的風險。

這和介面設計裡「移除選項」的邏輯一致。當一個設定項的兩個候選值對多數使用者已無可感知差異，保留它只會製造認知負擔與犯錯機會。JDK 27 仍允許顯式指定 -XX:+UseSerialGC，照顧需要極致啟動速度的場景，但把大多數人從這個決策裡解放出來。收走選擇的同時留下後門，這是成熟平臺的做派。

安全與工程：預設值裡的價值排序

其餘幾項也遵循同一套設計語言。JEP 527 讓 TLS 1.3 的後量子混合密鑰交換預設啟用，不需要改任何程式碼；JEP 536 給 JFR 加了進程內資料脫敏，敏感資訊自動處理。這兩項的共同點是：安全的正確行為被放進預設，而非留給使用者自行開啟。密碼學裡有句老話，最危險的預設就是需要人主動設定的安全。

預覽與孵化項目則扮演另一種角色。惰性常量（JEP 531，第三輪預覽）、原始型別模式匹配（JEP 532，第五輪預覽）、結構化併發（JEP 533，第七輪預覽）、Vector API（JEP 537，第十二輪孵化）。這些反覆出現的「第 N 輪」常被拿來調侃，但從設計流程看，它是一種極慢的灰度發布：先給志願者，收回意見，改一輪，再給。第十二輪孵化的 Vector API，等於被同一羣使用者檢視了十二次。這種節奏在消費性產品裡不可想像，但在一個承載全球金融系統的平臺上，慢本身是功能。

這與我們先前觀察過的AI 生成組件與設計系統的介面課題形成對照：工具鏈越自動化，預設值與庫存的品質就越決定下遊的整齊程度。Java 用二十多年把預設值磨到值得信賴，AI 工具鏈現在才剛開始學這件事。

結語：最好的升級是感覺不到的升級

JDK 27 的九項變更裡，真正有畫面感的其實很少。沒有新語法要在投影片上展示，沒有新框架要開研討會。最重的兩項，G1 全環境預設與緊湊物件頭，都是把已經被打磨到追平的方案，悄悄推上預設的位置。

這種發布方式本身是一種美學。它承認大多數使用者不會讀發布說明，於是把說明寫進行為裡。一個平臺對使用者的體貼，往往不在它提供了多少選項，而在它替你做了多少正確的決定。JDK 27 值得升級的原因，恰恰是升級之後，你幾乎察覺不到任何變化。