Java 7的這個新特性改變了警告的物件。構建這些型別畢竟有破壞型別安全的風險，這總得有人知道。但 API 的使用者對此是無能為力的，不管doSomething()是不是幹了壞事，破壞了型別安全，都不在API使用者的控制範圍之內。

真正需要看到這個警告資訊的是寫doSomething()的人，即API的建立者，而不是使用者。所以Java 7把警告資訊從使用API的地方挪到了定義API的地方。

過去是在編譯使用API的程式碼時觸發警告，而現在是在編譯這種可能會破壞型別安全的API時觸發。編譯器會警告建立這種API的程式設計師，讓他注意型別系統的安全。

為了減輕API開發人員的負擔，Java 7還提供了一個新註解java.lang.SafeVarargs。把這個註解應用到API方法或構造方法之中，則會產生型別警告。通過用@SafeVarargs對這種方法進行註解，開發人員就不會在裡面進行任何危險的操作，在這種情況下，編譯器就不會再發出警告了。

型別系統的修改

雖然把警告資訊從一個地方挪到另一個地方不是改變遊戲規則的語言特性，但也證明了我們之前提到的觀點——Coin專案曾奉勸諸位貢獻者遠離型別系統，因為把這麼一個小變化講清楚要大費周章。這個例子表明搞清楚型別系統不同特性之間如何互動是多麼費心費力，而且對語言的修改被實現後又會怎麼影響這種互動。這還不是特別複雜的修改，更大的變動所涉及的內容還會更多，其中還包括大量微妙的分支。

最後這個例子闡明瞭由小變化引發的錯綜複雜的影響。我們對Coin專案中改進的討論也結束了。儘管它們幾乎全都是語法上的小變化，但跟實現它們的程式碼量相比，它們所帶來的正面影響還是很可觀的。一旦開始使用，你就會發現這些特性對程式真的很有幫助！

小結

修改語言非常困難。而用類庫實現新特性總是相對容易一些，當然並不是所有特性都能用類庫實現。面對挑戰時，語言設計師可能會做出一些比他們的預想更輕微、更保守的調整。

現在，我們該去看看構成釋出版本更重要的東西了，先從Java 7中某些核心類庫的變化開始。我們的下一站是I/O類庫，那裡可以說是發生了天翻地覆的變化。在此之前，希望你已經掌握了Java之前的版本處理I/O的方法，因為Java 7中的這些類（有時候被稱為NIO.2）是構建在之前框架基礎之上的。

如果你想看到更多關於TWR實戰的例子，或者想要了解最新、高效能的I/O類，可以參考我們其他相關文章。