為何找不到Java 7中的警告

Java 7的這個新特性改變了警告的對象。構(gòu)建這些類型畢竟有破壞類型安全的風險，這總得有人知道。但 API 的用戶對此是無能為力的，不管doSomething()是不是干了壞事，破壞了類型安全，都不在API用戶的控制范圍之內(nèi)。

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

過去是在編譯使用API的代碼時觸發(fā)警告，而現(xiàn)在是在編譯這種可能會破壞類型安全的API時觸發(fā)。編譯器會警告創(chuàng)建這種API的程序員，讓他注意類型系統(tǒng)的安全。

為了減輕API開發(fā)人員的負擔，Java 7還提供了一個新注解java.lang.SafeVarargs。把這個注解應(yīng)用到API方法或構(gòu)造方法之中，則會產(chǎn)生類型警告。通過用@SafeVarargs對這種方法進行注解，開發(fā)人員就不會在里面進行任何危險的操作，在這種情況下，編譯器就不會再發(fā)出警告了。

類型系統(tǒng)的修改

雖然把警告信息從一個地方挪到另一個地方不是改變游戲規(guī)則的語言特性，但也證明了我們之前提到的觀點——Coin項目曾奉勸諸位貢獻者遠離類型系統(tǒng)，因為把這么一個小變化講清楚要大費周章。這個例子表明搞清楚類型系統(tǒng)不同特性之間如何交互是多么費心費力，而且對語言的修改被實現(xiàn)后又會怎么影響這種交互。這還不是特別復雜的修改，更大的變動所涉及的內(nèi)容還會更多，其中還包括大量微妙的分支。

最后這個例子闡明了由小變化引發(fā)的錯綜復雜的影響。我們對Coin項目中改進的討論也結(jié)束了。盡管它們幾乎全都是語法上的小變化，但跟實現(xiàn)它們的代碼量相比，它們所帶來的正面影響還是很可觀的。一旦開始使用，你就會發(fā)現(xiàn)這些特性對程序真的很有幫助！

小結(jié)

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

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

如果你想看到更多關(guān)于TWR實戰(zhàn)的例子，或者想要了解最新、高性能的I/O類，可以參考億速云其他相關(guān)文章。