增強的for循環
作為無可爭議的嬴家，新的for循環無論在何處（幾乎在任何地方）都非常好用，因此我激動得不知如何開始描述。當我被迫使用舊式for循環的時候，特別是需要使用索引或需要讓迭代程序在循環之外可見的時候，我的內心深處屢屢畏縮。 http://www.mscto.com
代碼具有很好的可讀性，並且給人的感覺一點也不繁雜（例如，索引不需要的代碼或增量公開基礎實現）。後面一點是新循環的意外收獲。試想一下，有如下代碼：
String[] names = ...;
for (String name :names) {
// ...
} 您決定把名稱類型改為Collection。如何修改代碼？ Listnames = ...; for (String name : names) { // ... } 軟件開發網
僅修改一行就可以了。這就是它的獨特優點。
注釋
顯然，我對注釋的了解還具有一定局限性，因為它們位於TestNG的核心位置；但是，我堅信注釋行將改變我們使用Java構建軟件的方式。長期以來，我們在程序中引入元數據一直依靠的是對黑客做出的反應，注釋最終將對此問題提供卓越的解決方案。 軟件開發網
此外，我有一個感覺，就是使用某些預定義的注釋（如@Override）是沒有必要的，所以在這一點上我一直沒有形成自己的意見。
在未來的若干年裡，對我來說一個無法逃避的現實是，我們閱讀和編寫的大多數Java代碼都將包含注釋。
靜態導入
除了在Retention 和 Target類型中，我幾乎不使用它們。至今還沒有人能說服我，添加此功能的本來意圖（阻止實現接口的反模式，且無需限定就能重用其常量）證明應該引入新的語言功能，這要讓時間說話。
我猜想，從某些方面來說，在我日常編程中使用的IDE完全廢棄了導入功能，所以我對這一功能已經沒有什麼感覺了。
可變長度參數
迄今為止，我從來不需要此功能。有時它可能用起來很方便，但是我真的不相信這種功能確保語言中的改變是正確的。
Enum 軟件開發網
理論上，我對Enum持肯定的態度，但是我還沒有真正把我的代碼轉換為Enum，所以我不了解它們的使用效果。我相信如果使用它們效果會很好，將使代碼更加健壯。
Generic
把最好的留到最後……但是因為本條目有點長，我將把對Generic的討論留作明天的話題。
Autoboxing
到目前為止，我還從來沒有使用過autoboxing功能，因為我對於代碼性能失去控制沒有明確的感覺。盡管autoboxing是一種未經證明的功能，它用起來方便，並且可以讓代碼更具有可讀性。我想我應該鼓勵開發人員在使用autoboxing時為代碼做上標記；我敢肯定IDE的開發人員不久也會這樣做。
軟件開發網
Generic
說在前面的話。 軟件開發網
首先，無可置疑，Generic是一個可能使代碼更加健壯的可靠概念。因為它具有可執行性，所以通常拋開具體語言對其進行討論。多年來作為C 委員會的成員，我清楚地感覺到正確使用它們決非易事。
簡言之，對Java generics我用下面的話來進行說明：代碼比以前健壯，但更加難以閱讀。
那麼，問題何在？
冗余。
首先，把一般的強制轉換需求引入冗余，對此問題我感覺很棘手。例如，為什麼不能不編寫：
Map accounts = new HashMap(); // no generics
...
Account a = (Account) accounts.get("Cedric");
而編寫： Map m = new HashMap(); // no generics
...
Account a = m.get("Cedric");
來代替，同時讓編譯器引入一種靜默強制轉換模式？因為很顯然，它是一個我試圖從Map中檢索的Account類型的對象。
http://www.mscto.com
顯然，Generic不能完全解決這個問題，只是在一定程度上有幫助而已。可是，在另外一些方面，它們卻有害無益：
Map<String, List<Account>> accounts =
new HashMap<String, List<Account>>();
嗨！
該代碼不僅難以閱讀，而且還未能遵守DRY（Don't repeat yourself）准則。如果我需要在列表<Account> Collection<Account>中更改此映射的值類型，將會發生什麼事？我需要替換代碼中的所有的此類聲明。盡管IDE重構對此有所幫助，仍然需要對相當多的代碼進行修改，此類修改甚至有可能對代碼的語義產生一定影響。
事實上，創建新對象時沒有什麼好辦法可以避免該語法，但是我要說的是，如果將typedef和Generic一起引入，情況會好的多。
我最初是這種觀點。 軟件開發網
但是，隨著認識的加深，我發現使用typedef解決問題是一個錯誤的解決方案，因為靠簡單添加的方式對使用單獨類定義復雜Generic類型沒有任何作用。 軟件開發網
class AccountMap extends HashMap<String, List&lAccount>> {
...
}
軟件開發網
除去擴展實現（很顯然是HashMap而不是Map）這種情況，該解決方案可能比引入typedef好一些，因為typedef有其自身的缺陷。 軟件開發網
迄今我還沒有遇到這種麻煩，但我的建議是：如果編寫該類型三次（初始化兩次，在代碼中使用一次以上）以上，則使用它。 軟件開發網
除此缺點外，總體來說我還是相當喜歡Generics的，而且尤其喜歡閱讀編寫的非常好的TestNG Javadocs。
結束語
對於JDK 5.0的新特性我非常滿意。我有幸參與了JSR 175和JSR 201，從而有機會對開發JDK 5.0的新特性作出了自己的貢獻。同所有根本性的變革一樣，不是所有的新特性都受到大家的歡迎，但隨著大多數開發人員發現其中某些特性非常有用，並且還保留了向後兼容性，我認為JDK 5.0向開發更多健壯的Java代碼邁出了堅定的一步。 軟件開發網
關於作者
軟件開發網
Cedric Beust的電子郵箱：[email protected]
博客：http://www.beust.com/weblog/
Cedric Beust是WebLogic Server團隊的高級軟件開發人員，他在其博客Otaku中提出了J2EE、Java、AOP和軟件開發等方面的見解。
