Java 8中類型注解是變的復雜還是便捷，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

創(chuàng)新互聯(lián)建站專注于科爾沁左翼網(wǎng)站建設服務及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供科爾沁左翼營銷型網(wǎng)站建設，科爾沁左翼網(wǎng)站制作、科爾沁左翼網(wǎng)頁設計、科爾沁左翼網(wǎng)站官網(wǎng)定制、小程序定制開發(fā)服務，打造科爾沁左翼網(wǎng)絡公司原創(chuàng)品牌,更為您提供科爾沁左翼網(wǎng)站排名全網(wǎng)營銷落地服務。

注解大家都知道，從java5開始加入這一特性，發(fā)展到現(xiàn)在已然是遍地開花，在很多框架中得到了廣泛的使用，用來簡化程序中的配置。那充滿爭議的類型注解究竟是什么？復雜還是便捷？

什么是類型注解

在java 8之前，注解只能是在聲明的地方所使用，比如類，方法，屬性；java 8里面，注解可以應用在任何地方，比如：

• 創(chuàng)建類實例

new @Interned MyObject();

• 類型映射

myString = (@NonNull String) str;

• implements 語句中

class UnmodifiableList implements @Readonly List<@Readonly T> { ... }

• throw exception聲明

void monitorTemperature() throws @Critical TemperatureException { ... }

需要注意的是，類型注解只是語法而不是語義，并不會影響java的編譯時間，加載時間，以及運行時間，也就是說，編譯成class文件的時候并不包含類型注解。

類型注解的作用

先看看下面代碼

Collections.emptyList().add("One"); int i=Integer.parseInt("hello"); System.console().readLine();

上面的代碼編譯是通過的，但運行是會分別報UnsupportedOperationException； NumberFormatException；NullPointerException異常，這些都是runtime error；

類型注解被用來支持在Java的程序中做強類型檢查。配合插件式的check framework，可以在編譯的時候檢測出runtime error，以提高代碼質(zhì)量。這就是類型注解的作用了。

check framework

check framework是第三方工具，配合Java的類型注解效果就是1+1>2。它可以嵌入到javac編譯器里面，可以配合ant和maven使用，也可以作為eclipse插件。地址是http://types.cs.washington.edu/checker-framework/。

check framework可以找到類型注解出現(xiàn)的地方并檢查，舉個簡單的例子：

import checkers.nullness.quals.*; public class GetStarted {     void sample() {         @NonNull Object ref = new Object();     } }

使用javac編譯上面的類

javac -processor checkers.nullness.NullnessChecker GetStarted.java

編譯是通過，但如果修改成

@NonNull Object ref = null;

再次編譯，則出現(xiàn)

GetStarted.java:5: incompatible types. found   : @Nullable  required: @NonNull Object         @NonNull Object ref = null;                               ^ 1 error

如果你不想使用類型注解檢測出來錯誤，則不需要processor，直接javac GetStarted.java是可以編譯通過的，這是在java 8 with Type Annotation Support版本里面可以，但java 5,6,7版本都不行，因為javac編譯器不知道@NonNull是什么東西，但check framework 有個向下兼容的解決方案，就是將類型注解nonnull用/**/注釋起來

，比如上面例子修改為

import checkers.nullness.quals.*; public class GetStarted {     void sample() {         /*@NonNull*/ Object ref = null;     } }

這樣javac編譯器就會忽略掉注釋塊，但用check framework里面的javac編譯器同樣能夠檢測出nonnull錯誤。

通過類型注解+check framework我們可以看到，現(xiàn)在runtime error可以在編譯時候就能找到。

關于JSR 308

JSR 308想要解決在Java 1.5注解中出現(xiàn)的兩個問題：

• 在句法上對注解的限制：只能把注解寫在聲明的地方

• 類型系統(tǒng)在語義上的限制：類型系統(tǒng)還做不到預防所有的bug

JSR 308 通過如下方法解決上述兩個問題：

• 對Java語言的句法進行擴充，允許注解出現(xiàn)在更多的位置上。包括：方法接收器（method receivers，譯注：例public int size() @Readonly { ... }），泛型參數(shù)，數(shù)組，類型轉(zhuǎn)換，類型測試，對象創(chuàng)建，類型參數(shù)綁定，類繼承和throws子句。其實就是類型注解，現(xiàn)在是java 8的一個特性

• 通過引入可插拔的類型系統(tǒng)（pluggable type systems）能夠創(chuàng)建功能更強大的注解處理器。類型檢查器對帶有類型限定注解的源碼進行分析，一旦發(fā)現(xiàn)不匹配等錯誤之處就會產(chǎn)生警告信息。其實就是check framework

對JSR308，有人反對，覺得更復雜更靜態(tài)了，比如

@NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>()>

換成動態(tài)語言為

var strings = ["one", "two"];

有人贊成，說到底，代碼才是“最根本”的文檔。代碼中包含的注解清楚表明了代碼編寫者的意圖。當沒有及時更新或者有遺漏的時候，恰恰是注解中包含的意圖信息，最容易在其他文檔中被丟失。而且將運行時的錯誤轉(zhuǎn)到編譯階段，不但可以加速開發(fā)進程，還可以節(jié)省測試時檢查bug的時間。

總結(jié)

并不是人人都喜歡這個特性，特別是動態(tài)語言比較流行的今天，所幸，java 8并不強求大家使用這個特性，反對的人可以不使用這一特性，而對代碼質(zhì)量有些要求比較高的人或公司可以采用JSR 308，畢竟代碼才是“最基本”的文檔，這句話我是贊同的。雖然代碼會增多，但可以使你的代碼更具有表達意義。對這個特性有何看法，大家各抒己見。。。。

看完上述內(nèi)容，你們掌握Java 8中類型注解是變的復雜還是便捷的方法了嗎？如果還想學到更多技能或想了解更多相關內(nèi)容，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！