您好,登錄后才能下訂單哦!
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類,可以參考億速云其他相關文章。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。