JDK 5 實戰心得：新特性優劣全評測 (含 Generics、Annotations、Enum、Autoboxing、Varargs、Enhanced For)

前言

作者 Cedric Beust (TestNG 作者、WebLogic 核心開發) 參與 JSR 175/201 制定，分享半年 JDK 5 實戰經驗。本文針對六大核心特性給出一線開發視角的優劣評價。

一、Enhanced For Loop (增強型 for 迴圈) —— 無可爭議的贏家

優點

• 語法簡潔：for (String name : names) { ... }
• 消除索引變數、邊界檢查、Iterator 樣板碼。
• 重構極其容易：將 String[] 改為 List<String> 僅需修改宣告行，迴圈體完全不用動。

缺點

• 無法存取索引值 (需手動計數器)。
• 無法在迴圈中移除集合元素 (需用 Iterator.remove())。

評價

⭐⭐⭐⭐⭐ 日常開發首選，極大提升可讀性與維護性。

二、Annotations (註解) —— 將改變軟體建構方式

現狀

長期以來，Java 缺乏標準元資料機制，開發者靠命名慣例、XDoclet、屬性檔、介面標記等「駭客手段」攜帶元資料。Annotations 提供標準化、型別安全、運行時可反射的元資料載體。

核心價值

• 宣告式配置取代 XML (EJB 3.0、Spring、Hibernate、JUnit 4、TestNG)。
• 編譯期檢查 (如 @Override、@Deprecated、@SuppressWarnings)。
• APT (Annotation Processing Tool) 實現原始碼生成 (Lombok、MapStruct、Dagger、Room)。

爭議點

@Override 等內建註解是否必要？作者持保留態度，但承認未來幾年絕大多數 Java 程式碼將包含註解。

評價

⭐⭐⭐⭐⭐ 生態系統變革者，現代 Java 框架基石。

三、Static Import (靜態導入) —— 雞肋功能

設計初衷

防止「實作介面只為繼承常數」反模式，允許直接使用 Math.PI、Color.RED 等靜態成員。

實戰感受

• IDE (IntelliJ/Eclipse) 自動管理 Import，手寫 Import 已成過去式。
• 濫用會降低可讀性 (常數來源不明)。
• 作者幾乎不使用，除非在測試程式碼大量呼叫斷言方法。

評價

⭐⭐ 語法糖，非必要，團隊需制定編碼規範限制使用範圍。

四、Varargs (可變長度參數) —— 方便但非必需

語法

public void printf(String format, Object... args) { ... }

實戰感受

• 偶爾方便 (如日誌、格式化、測試輔助方法)。
• 底層仍是陣列，呼叫端隱性建立陣列物件，微小效能開銷。
• 重載解析規則複雜，易產生歧義。
• 作者從未「必須」用到它。

評價

⭐⭐⭐ 語法糖，適度使用無妨，勿濫用。

五、Enum (列舉型別) —— 理論優秀，遲遲未遷移

優點

• 型別安全：編譯期防止非法常數傳入。
• 可攜帶行為 (方法、欄位)、實作介面、支援 Switch。
• 單例模式最佳實作方式 (Joshua Bloch 推薦)。

遲未遷移原因

既有代碼庫大量使用 public static final int 常數，遷移成本高、風險大，且 IDE 重構支援有限。

評價

⭐⭐⭐⭐ 新專案強烈建議使用，舊代碼按需遷移。

六、Generics (泛型) —— 代碼更健壯，但更難閱讀

核心價值

• 編譯期型別檢查，消除 ClassCastException 風險。
• API 契約明確化：List<String> 比 List 表達力強得多。

痛點：冗長與 DRY 原則違背

// 宣告與實例化雙重指定型別參數
Map<String, List<Account>> accounts = new HashMap<String, List<Account>>();

• 菱形語法 new HashMap<>() 為 JDK 7 才引入，JDK 5 必須重複寫兩次。
• 巢狀泛型嚴重影響可讀性。
• 修改值型別 (如 List<Account> → Collection<Account>) 需全域搜尋替換。

變通方案

• 定義子類別封裝複雜泛型：class AccountMap extends HashMap<String, List<Account>> {} (但繼承實作類而非介面)。
• 作者建議：同一複雜型別出現超過 3 次 (宣告 2 次 + 使用 1 次以上) 才封裝。

類型擦除帶來的限制

• 運行時無法獲知泛型參數 (無法 new T()、T.class、instanceof List<String>)。
• 橋接方法、原始型別兼容性導致不可預期警告。

評價

⭐⭐⭐⭐ 大勢所趨，長期收益遠大於短期適應成本，配合 IDE 輔助可控制複雜度。

七、Autoboxing (自動裝箱/拆箱) —— 方便但隱藏效能陷阱

現象

Integer i = 10;        // 自動裝箱 Integer.valueOf(10)
int j = i;             // 自動拆箱 i.intValue()
i += 1;                // 拆箱 → 運算 → 裝箱，產生新 Integer 物件

風險

• 迴圈中大量裝箱/拆箱產生海量暫時物件，觸發 GC 壓力。
• Integer 快取範圍 -128~127，超出範圍 == 比較失效。
• NullPointerException 風險：Integer i = null; int j = i; 拋出 NPE。

作者策略

暫不使用，建議 IDE 標記裝箱/拆箱位置，團隊制定規範 (如禁止在熱點路徑使用)。

評價

⭐⭐⭐ 語法糖，明確理解行為後可用於非效能敏感路徑。

八、總結與展望

JDK 5 並非完美，但以向後相容方式推進了 Java 型別系統與元資料能力的根本性飛躍。隨著開發者逐漸掌握最實用的子集，Java 邁向更健壯、更具表達力的新紀元。

作者簡介

Cedric Beust，WebLogic Server 高級工程師，TestNG 作者，JSR 175 (Annotations) / JSR 201 (Generics) 專家組成員。部落格：Otaku。