建站
咨詢
售后
建站咨詢
新聞中心
劃重點(diǎn)
自 JDK5 推出以來，注解已成為Java生態(tài)系統(tǒng)不可缺少的一部分。雖然開發(fā)者為Java框架（例如Spring的@Autowired）開發(fā)了無數(shù)的自定義注解，但編譯器認(rèn)可的一些注解非常重要。
創(chuàng)新互聯(lián)網(wǎng)站建設(shè)服務(wù)商，為中小企業(yè)提供網(wǎng)站建設(shè)、網(wǎng)站制作服務(wù)，網(wǎng)站設(shè)計，成都網(wǎng)站托管等一站式綜合服務(wù)型公司，專業(yè)打造企業(yè)形象網(wǎng)站，讓您在眾多競爭對手中脫穎而出創(chuàng)新互聯(lián)。
在本文中，我們將看到5個Java編譯器支持的注解，并了解其期望用途。順便，我們將探索其創(chuàng)建背后的基本原理，圍繞其用途的一些特質(zhì)，以及正確應(yīng)用的一些例子。雖然其中有些注解比其他注解更為常見，但非初學(xué)Java開發(fā)人員都應(yīng)該消化了解每個注解。
- @Override
- @FunctionalInterface
- @SuppressWarnings
- @SafeVarargs
- @Deprecated
首先，我們將深入研究Java中最常用的注解之一：@Override。
@Override
覆蓋方法的實(shí)現(xiàn)或?yàn)槌橄蠓椒ㄌ峁?shí)現(xiàn)的能力是任何面向?qū)ο螅∣O）語言的核心。由于Java是OO語言，具有許多常見的面向?qū)ο蟮某橄髾C(jī)制，所以在非***超類定義的非最終方法或接口中的任何方法（接口方法不能是最終的）都可以被子類覆蓋。點(diǎn)擊這里閱讀 Java 10 新特性實(shí)戰(zhàn)教程。
雖然開始時覆蓋方法看起來很簡單，但是如果執(zhí)行不正確，則可能會引入許多微小的bug。例如，用覆蓋類類型的單個參數(shù)覆蓋Object#equals方法就是一種常見的錯誤：
- public class Foo { public boolean equals(Foo foo) { // Check if the supplied object is equal to this object
- }
- }
由于所有類都隱式地從Object類繼承，F(xiàn)oo類的目的是覆蓋Object#equals方法，因此Foo可被測試是否與Java中的任何其他對象相等。雖然我們的意圖是正確的，但我們的實(shí)現(xiàn)則并非如此。
實(shí)際上，我們的實(shí)現(xiàn)根本不覆蓋Object#equals方法。相反，我們提供了方法的重載：我們不是替換Object類提供的equals方法的實(shí)現(xiàn)，而是提供第二個方法來專門接受Foo對象，而不是Object對象。
我們的錯誤可以用簡單實(shí)現(xiàn)來舉例說明，該實(shí)現(xiàn)對所有的相等檢查都返回true，但當(dāng)提供的對象被視為Object（Java將執(zhí)行的操作，例如在Java Collections Framework即JCF中）時，就永遠(yuǎn)不會調(diào)用它：
- public class Foo { public boolean equals(Foo foo) { return true;
- }
- }
- Object foo = new Foo();
- Object identicalFoo = new Foo();
- System.out.println(foo.equals(identicalFoo)); // false
這是一個非常微妙但常見的錯誤，可以被編譯器捕獲。我們的意圖是覆蓋Object#equals方法，但因?yàn)槲覀冎付艘粋€類型為Foo而不是Object類型的參數(shù)，所以我們實(shí)際上提供了重載的Object#equals方法，而不是覆蓋它。為了捕獲這種錯誤，我們引入@Override注解，它指示編譯器檢查覆蓋實(shí)際有沒有執(zhí)行。如果沒有執(zhí)行有效的覆蓋，則會拋出錯誤。因此，我們可以更新Foo類，如下所示：
- public class Foo { @Override
- public boolean equals(Foo foo) { return true;
- }
- }
如果我們嘗試編譯這個類，我們現(xiàn)在收到以下錯誤：
- $ javac Foo.java
- Foo.java:3: error: method does not override or implement a method from a supertype
- @Override
- ^1 error
實(shí)質(zhì)上，我們已經(jīng)將我們已經(jīng)覆蓋方法的這一隱含的假設(shè)轉(zhuǎn)變?yōu)橛删幾g器進(jìn)行的顯性驗(yàn)證。如果我們的意圖被錯誤地實(shí)現(xiàn)，那么Java編譯器會發(fā)出一個錯誤——不允許我們不正確實(shí)現(xiàn)的代碼被成功編譯。通常，如果以下任一條件不滿足，則Java編譯器將針對使用@Override注解的方法發(fā)出錯誤（引用自O(shè)verride注解文檔）：
- 該方法確實(shí)會覆蓋或?qū)崿F(xiàn)在超類中聲明的方法。
- 該方法的簽名與在Object中聲明的任何公共方法（即equals或hashCode方法）的簽名覆蓋等價（override-equivalent）。
因此，我們也可以使用此注解來確保子類方法實(shí)際上也覆蓋超類中的非最終具體方法或抽象方法：
- public abstract class Foo { public int doSomething() { return 1;
- } public abstract int doSomethingElse();
- }public class Bar extends Foo { @Override
- public int doSomething() { return 10;
- } @Override
- public int doSomethingElse() { return 20;
- }
- }
- Foo bar = new Bar();
- System.out.println(bar.doSomething()); // 10System.out.println(bar.doSomethingElse()); // 20
@Override注解不僅不限于超類中的具體或抽象方法，而且還可用于確保接口的方法也被覆蓋（從JDK 6開始）：
- public interface Foo { public int doSomething();
- }public class Bar implements Foo { @Override
- public int doSomething() { return 10;
- }
- }
- Foo bar = new Bar();
- System.out.println(bar.doSomething()); // 10
通常，覆蓋非final類方法、抽象超類方法或接口方法的任何方法都可以使用@Override進(jìn)行注解。有關(guān)有效覆蓋的更多信息，請參閱《Overriding and Hiding》文檔 以及《Java Language Specification (JLS)》的第9.6.4.4章節(jié)。
@FunctionalInterface
隨著JDK 8中l(wèi)ambda表達(dá)式的引入，函數(shù)式接口在Java中變得越來越流行。這些特殊類型的接口可以用lambda表達(dá)式、方法引用或構(gòu)造函數(shù)引用代替。根據(jù)@FunctionalInterface文檔，函數(shù)式接口的定義如下：
一個函數(shù)式接口只有一個抽象方法。由于默認(rèn)方法有一個實(shí)現(xiàn)，所以它們不是抽象的。
例如，以下接口被視為函數(shù)式接口：
- public interface Foo { public int doSomething();
- }
- public interface Bar { public int doSomething(); public default int doSomethingElse() { return 1;
- }
- }
因此，下面的每一個都可以用lambda表達(dá)式代替，如下所示：
- public class FunctionalConsumer { public void consumeFoo(Foo foo) {
- System.out.println(foo.doSomething());
- } public void consumeBar(Bar bar) {
- System.out.println(bar.doSomething());
- }
- }
- FunctionalConsumer consumer = new FunctionalConsumer();
- consumer.consumeFoo(() -> 10); // 10consumer.consumeBar(() -> 20); // 20
重點(diǎn)要注意的是，抽象類，即使它們只包含一個抽象方法，也不是函數(shù)式接口。更多信息，請參閱***Java語言架構(gòu)師Brian Goetz編寫的《Allow lambdas to implement abstract classes》。與@Override注解類似，Java編譯器提供了@FunctionalInterface注解以確保接口確實(shí)是函數(shù)式接口。例如，我們可以將此注解添加到上面創(chuàng)建的接口中：
- @FunctionalInterfacepublic interface Foo { public int doSomething();
- }@FunctionalInterfacepublic interface Bar { public int doSomething(); public default int doSomethingElse() { return 1;
- }
- }
如果我們錯誤地將接口定義為非函數(shù)接口并用@FunctionalInterface注解了錯誤的接口，則Java編譯器會發(fā)出錯誤。例如，我們可以定義以下帶注解的非函數(shù)式接口：
- @FunctionalInterfacepublic interface Foo { public int doSomething(); public int doSomethingElse();
- }
如果我們試圖編譯這個接口，則會收到以下錯誤：
- $ javac Foo.java
- Foo.java:1: error: Unexpected @FunctionalInterface annotation
- @FunctionalInterface
- ^
- Foo is not a functional interface
- multiple non-overriding abstract methods found in interface Foo1 error
使用這個注解，我們可以確保我們不會錯誤地創(chuàng)建原本打算用作函數(shù)式接口的非函數(shù)式接口。需要注意的是，即使在@FunctionalInterface注解不存在的情況下，接口也可以用作函數(shù)式接口（可以替代為lambdas，方法引用和構(gòu)造函數(shù)引用），正如我們前面的示例中所見的那樣。這類似于@Override注解，即一個方法是可以被覆蓋的，即使它不包含@Override注解。在這兩種情況下，注解都是允許編譯器執(zhí)行期望意圖的可選技術(shù)。
有關(guān)@FunctionalInterface注解的更多信息，請參閱@FunctionalInterface文檔和《JLS》的第4.6.4.9章節(jié)。點(diǎn)擊這里閱讀 Java 10 新特性實(shí)戰(zhàn)教程。
@SuppressWarnings
警告是所有編譯器的重要組成部分，為開發(fā)人員提供的反饋——可能危險的行為或在未來的編譯器版本中可能會出現(xiàn)的錯誤。例如，在Java中使用泛型類型而沒有其關(guān)聯(lián)的正式泛型參數(shù)（稱為原始類型）會導(dǎo)致警告，就像使用不推薦使用的代碼一樣（請參閱下面的@Deprecated部分）。雖然這些警告很重要，但它們可能并不總是適用甚至并不總是正確的。例如，可能會有對不安全的類型轉(zhuǎn)換發(fā)生警告的情況，但是基于使用它的上下文，我們可以保證它是安全的。
為了忽略某些上下文中的特定警告，JDK 5中引入了@SuppressWarnings注解。此注解接受一個或多個字符串參數(shù)——描述要忽略的警告名稱。雖然這些警告的名稱通常在編譯器實(shí)現(xiàn)之間有所不同，但有3種警告在Java語言中是標(biāo)準(zhǔn)化的（因此在所有Java編譯器實(shí)現(xiàn)中都很常見）：
- unchecked：表示類型轉(zhuǎn)換未經(jīng)檢查的警告（編譯器無法保證類型轉(zhuǎn)換是安全的），導(dǎo)致發(fā)生的可能原因有訪問原始類型的成員（參見《JLS》4.8章節(jié)）、窄參考轉(zhuǎn)換或不安全的向下轉(zhuǎn)換（參見《JLS》5.1.6章節(jié)）、未經(jīng)檢查的類型轉(zhuǎn)換（參見《JLS》5.1.9章節(jié)）、使用帶有可變參數(shù)的泛型參數(shù)（參見《JLS》8.4.1章節(jié)和下面的@SafeVarargs部分）、使用無效的協(xié)變返回類型（參見《JLS》8.4.8.3章節(jié)）、不確定的參數(shù)評估（參見《JLS》15.12.4.2章節(jié)），未經(jīng)檢查的方法引用類型的轉(zhuǎn)換（參見《JLS》15.13.2章節(jié)）、或未經(jīng)檢查的lambda類型的對話（參見《JLS》15.27.3章節(jié)）。
- deprecation：表示使用了已棄用的方法、類、類型等的警告（參見《JLS》9.6.4.6章節(jié)和下面的@Deprecated部分）。
- removal：表示使用了最終廢棄的方法、類、類型等的警告（參見《JLS》9.6.4.6章節(jié)和下面的@Deprecated部分）。
為了忽略特定的警告，可以將@SuppressedWarning注解與抑制警告（以字符串?dāng)?shù)組的形式提供）的一個或多個名字添加到發(fā)生警告的上下文中：
- public class Foo { public void doSomething(@SuppressWarnings("rawtypes") List myList) { // Do something with myList
- }
- }
@SuppressWarnings注解可用于以下任何一種情況：
- 類型
- 域
- 方法
- 參數(shù)
- 構(gòu)造函數(shù)
- 局部變量
- 模塊
一般來說，@SuppressWarnings注解應(yīng)該應(yīng)用于最直接的警告范圍。例如，如果方法中的局部變量應(yīng)忽略警告，則應(yīng)將@SuppressWarnings注解應(yīng)用于局部變量，而不是包含局部變量的方法或類：
- public class Foo { public void doSomething() { @SuppressWarnings("rawtypes")
- List myList = new ArrayList(); // Do something with myList
- }
- }
@SafeVarargs
可變參數(shù)在Java中是一種很有用的技術(shù)手段，但在與泛型參數(shù)一起使用時，它們也可能會導(dǎo)致一些嚴(yán)重的問題。由于泛型在Java中是非特定的，所以具有泛型類型的變量的實(shí)際（實(shí)現(xiàn)）類型不能在運(yùn)行時被斷定。由于無法做出此判斷，因此變量可能會存儲非其實(shí)際類型的引用到類型，如以下代碼片段所示（摘自《Java Generics FAQs》）：
- List ln = new ArrayList
(); - ln.add(1);
- List
ls = ln; // unchecked warning String s = ls.get(0); // ClassCastException
在將ln分配給ls后，堆中存在變量ls，該變量具有List
- public class Foo { public
void doSomething(T... args) { // ... - }
- }
在這種情況下，Java編譯器會在調(diào)用站點(diǎn)內(nèi)部創(chuàng)建一個數(shù)組來存儲可變數(shù)量的參數(shù)，但是T的類型并未實(shí)現(xiàn)，因此在運(yùn)行時會丟失。實(shí)質(zhì)上，到doSomething的參數(shù)實(shí)際上是Object[]類型。如果依賴T的運(yùn)行時類型，那么這會導(dǎo)致嚴(yán)重的問題，如下面的代碼片段所示：
- public class Foo {
- public
void doSomething(T... args) { Object[] objects = args; String string = (String) objects[0]; - }
- }
- Foo foo = new Foo();
- foo.
doSomething(1, 2);
如果執(zhí)行此代碼片段，那么將導(dǎo)致ClassCastException，因?yàn)樵谡{(diào)用站點(diǎn)傳遞的***個Number參數(shù)不能轉(zhuǎn)換為String（類似于獨(dú)立堆污染示例中拋出的ClassCastException）。通常，可能會出現(xiàn)以下情況：編譯器沒有足夠的信息來正確確定通用可變參數(shù)的確切類型，這會導(dǎo)致堆污染，這種污染可以通過允許內(nèi)部可變參數(shù)數(shù)組從方法中轉(zhuǎn)義來傳播，如下面摘自《Effective Java》第3版 pp.147的例子：
- public static
T[] toArray(T... args) { return args; - }
在某些情況下，我們知道方法實(shí)際上是類型安全的，不會造成堆污染。如果可以在保證的情況下做出這個決定，那么我們可以使用@SafeVarargs注解來注解該方法，從而抑制與可能的堆污染相關(guān)的警告。但是，這引出了一個問題：什么時候通用可變參數(shù)方法會被認(rèn)為是類型安全的？Josh Bloch在《Effective Java》第3版第147頁的基礎(chǔ)上提供了一個完善的解決方案——基于方法與內(nèi)部創(chuàng)建的用于存儲其可變參數(shù)的數(shù)組的交互：
如果方法沒有存儲任何東西到數(shù)組（這會覆蓋參數(shù)）且不允許對數(shù)組的引用進(jìn)行轉(zhuǎn)義（這會使得不受信任的代碼可以訪問數(shù)組），那么它是安全的。換句話說，如果可變參數(shù)數(shù)組僅用于從調(diào)用者向方法傳遞可變數(shù)量的參數(shù)——畢竟，這是可變參數(shù)的目的——那么該方法是安全的。
因此，如果我們創(chuàng)建了以下方法（來自pp.149同上），那么我們可以用@SafeVarags注解來合理地注解我們的方法：
- @SafeVarargsstatic
List flatten(List... lists) { List result = new ArrayList<>(); for (List list : lists) { - result.addAll(list);
- } return result;
- }
有關(guān)@SafeVarargs注解的更多信息，請參閱@SafeVarargs文檔，《JLS》9.6.4.7章節(jié)以及《Effective Java》第3版中的Item32。點(diǎn)擊這里閱讀 Java 10 新特性實(shí)戰(zhàn)教程。
@Deprecated
在開發(fā)代碼時，有時候代碼會變得過時和不應(yīng)該再被使用。在這些情況下，通常會有個替補(bǔ)的更適合手頭的任務(wù)，且雖然現(xiàn)存的對過時代碼的調(diào)用可能會保留，但是所有新的調(diào)用都應(yīng)該使用替換方法。這個過時的代碼被稱為不推薦使用的代碼。在某些緊急情況下，不建議使用的代碼可能會被刪除，應(yīng)該在未來的框架或庫版本從其代碼庫中刪除棄用的代碼之前立即轉(zhuǎn)換為替換代碼。
為了支持不推薦使用的代碼的文檔，Java包含@Deprecated注解，它會將一些構(gòu)造函數(shù)、域、局部變量、方法、軟件包、模塊、參數(shù)或類型標(biāo)記為已棄用。如果棄用的元素（構(gòu)造函數(shù)，域，局部變量等）被使用了，則編譯器發(fā)出警告。例如，我們可以創(chuàng)建一個棄用的類并按如下所示使用它：
- @Deprecatedpublic class Foo {}
- Foo foo = new Foo();
如果我們編譯此代碼（在命名為Main.java的文件中），我們會收到以下警告：
- $ javac Main.javaNote: Main.java uses or overrides a deprecated API.Note: Recompile with -Xlint:deprecation for details.
通常，每當(dāng)使用@Deprecated注解的元素時，都會引發(fā)警告，除了用于以下五種情況：
- 聲明本身就被聲明為是棄用的（即遞歸調(diào)用）。
- 聲明被注解禁止棄用警告（即@SuppressWarnings(“deprecation”）注解，如上所述，應(yīng)用于使用棄用元素的上下文。
- 使用和聲明都在同一個最外面的類中（即，如果類調(diào)用其本身的棄用方法）。
- 用在import聲明中，該聲明導(dǎo)入通常不贊成使用的類型或構(gòu)件（即，在將已棄用的類導(dǎo)入另一個類時）。
- exports或opens指令內(nèi)。
正如前面所說的，在某些情況下，當(dāng)不推薦使用的元素將被刪除，則調(diào)用代碼應(yīng)立即刪除不推薦使用的元素（稱為terminally deprecated code）。在這種情況下，可以使用forRemoval參數(shù)提供的@Deprecated注解，如下所示：
- @Deprecated(forRemoval = true)public class Foo {}
使用此最終棄用代碼會導(dǎo)致一系列更嚴(yán)格的警告：
- $ javac Main.java
- Main.java:7: warning: [removal] Foo in com.foo has been deprecated and marked for removal
- Foo foo = new Foo();
- ^
- Main.java:7: warning: [removal] Foo in com.foo has been deprecated and marked for removal
- Foo foo = new Foo();
- ^2 warnings
除了標(biāo)準(zhǔn)@Deprcated注解所描述的相同異常之外，總是會發(fā)出最終棄用的警告。我們還可以通過為注解提供since變量來添加文檔到@Deprecated注解中：
- @Deprecated(since = "1.0.5", forRemoval = true)public class Foo {}
可以使用@deprecated JavaDoc元素（注意小寫字母d）進(jìn)一步文檔化已棄用的元素，如以下代碼片段所示：
- /**
- * Some test class.
- *
- * @deprecated Replaced by {@link com.foo.NewerFoo}.
- *
- * @author Justin Albano
- */@Deprecated(since = "1.0.5", forRemoval = true)public class Foo {}
JavaDoc工具將生成以下文檔：
有關(guān)@Deprecated注解的更多信息，請參閱@Deprecated文檔和《JLS》9.6.4.6章節(jié)。
結(jié)尾
自JDK 5引入注解以來，注解一直是Java不可缺少的一部分。雖然有些注解比其他注解更受歡迎，但本文中介紹的這5種注解是新手級別以上的開發(fā)人員都應(yīng)該理解和掌握的：
- @Override
- @FunctionalInterface
- @SuppressWarnings
- @SafeVarargs
- @Deprecated
雖然每種方法都有其獨(dú)特的用途，但所有這些注解使得Java應(yīng)用程序更具可讀性，并允許編譯器對我們的代碼執(zhí)行一些其他隱含的假設(shè)。隨著Java語言的不斷發(fā)展，這些經(jīng)過實(shí)踐驗(yàn)證的注解可能服務(wù)多年，幫助確保更多的應(yīng)用程序按開發(fā)人員的意圖行事。
新聞名稱：Java程序員必須掌握的5個注解！
瀏覽路徑：http://www.5511xx.com/article/dhgjpje.html
