Java 8新特性探究(4):類型注解 復(fù)雜還是便捷
注解大家都知道,從java5開始加入這一特性,發(fā)展到現(xiàn)在已然是遍地開花,在很多框架中得到了廣泛的使用,用來簡(jiǎn)化程序中的配置。那充滿爭(zhēng)議的類型注解究竟是什么?復(fù)雜還是便捷?
什么是類型注解
在java 8之前,注解只能是在聲明的地方所使用,比如類,方法,屬性;java 8里面,注解可以應(yīng)用在任何地方,比如:
- 創(chuàng)建類實(shí)例
new @Interned MyObject();
- 類型映射
myString = (@NonNull String) str;
- implements 語句中
class UnmodifiableList<T> implements @Readonly List<@Readonly T> { ... }
- throw exception聲明
void monitorTemperature() throws @Critical TemperatureException { ... }
需要注意的是,類型注解只是語法而不是語義,并不會(huì)影響java的編譯時(shí)間,加載時(shí)間,以及運(yùn)行時(shí)間,也就是說,編譯成class文件的時(shí)候并不包含類型注解。
類型注解的作用
先看看下面代碼
- Collections.emptyList().add("One");
- int i=Integer.parseInt("hello");
- System.console().readLine();
上面的代碼編譯是通過的,但運(yùn)行是會(huì)分別報(bào)UnsupportedOperationException; NumberFormatException;NullPointerException異常,這些都是runtime error;
類型注解被用來支持在Java的程序中做強(qiáng)類型檢查。配合插件式的check framework,可以在編譯的時(shí)候檢測(cè)出runtime error,以提高代碼質(zhì)量。這就是類型注解的作用了。
check framework
check framework是第三方工具,配合Java的類型注解效果就是1+1>2。它可以嵌入到j(luò)avac編譯器里面,可以配合ant和maven使用,也可以作為eclipse插件。地址是http://types.cs.washington.edu/checker-framework/。
check framework可以找到類型注解出現(xiàn)的地方并檢查,舉個(gè)簡(jiǎ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 <nulltype>
- required: @NonNull Object
- @NonNull Object ref = null;
- ^
- 1 error
如果你不想使用類型注解檢測(cè)出來錯(cuò)誤,則不需要processor,直接javac GetStarted.java是可以編譯通過的,這是在java 8 with Type Annotation Support版本里面可以,但java 5,6,7版本都不行,因?yàn)閖avac編譯器不知道@NonNull是什么東西,但check framework 有個(gè)向下兼容的解決方案,就是將類型注解nonnull用/**/注釋起來
,比如上面例子修改為
- import checkers.nullness.quals.*;
- public class GetStarted {
- void sample() {
- /*@NonNull*/ Object ref = null;
- }
- }
這樣javac編譯器就會(huì)忽略掉注釋塊,但用check framework里面的javac編譯器同樣能夠檢測(cè)出nonnull錯(cuò)誤。
通過類型注解+check framework我們可以看到,現(xiàn)在runtime error可以在編譯時(shí)候就能找到。
關(guān)于JSR 308
JSR 308想要解決在Java 1.5注解中出現(xiàn)的兩個(gè)問題:
- 在句法上對(duì)注解的限制:只能把注解寫在聲明的地方
- 類型系統(tǒng)在語義上的限制:類型系統(tǒng)還做不到預(yù)防所有的bug
JSR 308 通過如下方法解決上述兩個(gè)問題:
- 對(duì)Java語言的句法進(jìn)行擴(kuò)充,允許注解出現(xiàn)在更多的位置上。包括:方法接收器(method receivers,譯注:例public int size() @Readonly { ... }),泛型參數(shù),數(shù)組,類型轉(zhuǎn)換,類型測(cè)試,對(duì)象創(chuàng)建,類型參數(shù)綁定,類繼承和throws子句。其實(shí)就是類型注解,現(xiàn)在是java 8的一個(gè)特性
- 通過引入可插拔的類型系統(tǒng)(pluggable type systems)能夠創(chuàng)建功能更強(qiáng)大的注解處理器。類型檢查器對(duì)帶有類型限定注解的源碼進(jìn)行分析,一旦發(fā)現(xiàn)不匹配等錯(cuò)誤之處就會(huì)產(chǎn)生警告信息。其實(shí)就是check framework
對(duì)JSR308,有人反對(duì),覺得更復(fù)雜更靜態(tài)了,比如
- @NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>()>
換成動(dòng)態(tài)語言為
- var strings = ["one", "two"];
有人贊成,說到底,代碼才是“最根本”的文檔。代碼中包含的注解清楚表明了代碼編寫者的意圖。當(dāng)沒有及時(shí)更新或者有遺漏的時(shí)候,恰恰是注解中包含的意圖信息,最容易在其他文檔中被丟失。而且將運(yùn)行時(shí)的錯(cuò)誤轉(zhuǎn)到編譯階段,不但可以加速開發(fā)進(jìn)程,還可以節(jié)省測(cè)試時(shí)檢查bug的時(shí)間。
總結(jié)
并不是人人都喜歡這個(gè)特性,特別是動(dòng)態(tài)語言比較流行的今天,所幸,java 8并不強(qiáng)求大家使用這個(gè)特性,反對(duì)的人可以不使用這一特性,而對(duì)代碼質(zhì)量有些要求比較高的人或公司可以采用JSR 308,畢竟代碼才是“最基本”的文檔,這句話我是贊同的。雖然代碼會(huì)增多,但可以使你的代碼更具有表達(dá)意義。對(duì)這個(gè)特性有何看法,大家各抒己見。。。。
原文鏈接:http://my.oschina.net/benhaile/blog/179642