@SuppressWarnings與前兩個注釋有所不同，你需要添加一個參數(shù)才能正確使用，這些參數(shù)值都是已經(jīng)定義好了的，我們選擇性的使用就好了，參數(shù)如下：
|
參數(shù)
|
語義
|
|
deprecation
|
使用了過時的類或方法時的警告
|
|
unchecked
|
執(zhí)行了未檢查的轉(zhuǎn)換時的警告，例如當(dāng)使用集合時沒有用泛型 (Generics) 來指定集合保存的類型
|
|
fallthrough
|
當(dāng) Switch 程序塊直接通往下一種情況而沒有 Break 時的警告
|
|
path
|
在類路徑、源文件路徑等中有不存在的路徑時的警告
|
|
serial
|
當(dāng)在可序列化的類上缺少 serialVersionUID 定義時的警告
|
|
finally
|
任何 finally 子句不能正常完成時的警告
|
|
all
|
關(guān)于以上所有情況的警告
|
Override
Override表示，它所注釋的方法應(yīng)該重寫超類中具有相同簽名的方法：
@Override
public int hashCode() {
...
}
看上面的例子，如果沒有在hashCode中將“C”大寫，在編譯時不會出現(xiàn)錯誤，但是在運(yùn)行時將無法像期望的那樣調(diào)用該方法。通過添加Override標(biāo)簽，編譯器會提示它是否真正地執(zhí)行了重寫。
在超類發(fā)生改變的情況中，這也很有幫助。如果向該方法中添加一個新參數(shù)，而且方法本身也被重命名了，那么子類將突然不能編譯，因?yàn)樗辉僦貙懗惖娜魏螙|西。
枚舉
enum非常像public static final int聲明，后者作為枚舉值已經(jīng)使用了很多年。對int所做的最大也是最明顯的改進(jìn)是類型安全――您不能錯誤地用枚舉的一種類型代替另一種類型，這一點(diǎn)和int不同，所有的int對編譯器來說都是一樣的。除去極少數(shù)例外的情況，通常都應(yīng)該用enum實(shí)例替換全部的枚舉風(fēng)格的int結(jié)構(gòu)。
枚舉提供了一些附加的特性。EnumMap和EnumSet這兩個實(shí)用類是專門為枚舉優(yōu)化的標(biāo)準(zhǔn)集合實(shí)現(xiàn)。如果知道集合只包含枚舉類型，那么應(yīng)該使用這些專門的集合來代替HashMap或HashSet。
大部分情況下，可以使用enum對代碼中的所有public static final int做插入替換。它們是可比的，并且可以靜態(tài)導(dǎo)入，所以對它們的引用看起來是等同的，即使是對于內(nèi)部類（或內(nèi)部枚舉類型）。注意，比較枚舉類型的時候，聲明它們的指令表明了它們的順序值。
“隱藏的”靜態(tài)方法
兩個靜態(tài)方法出現(xiàn)在所有枚舉類型聲明中。因?yàn)樗鼈兪敲杜e子類上的靜態(tài)方法，而不是Enum本身的方法，所以它們在java.lang.Enum的javadoc中沒有出現(xiàn)。
第一個是values()，返回一個枚舉類型所有可能值的數(shù)組。
第二個是valueOf()，為提供的字符串返回一個枚舉類型，該枚舉類型必須精確地匹配源代碼聲明。
方法
關(guān)于枚舉類型，我們最喜歡的一個方面是它可以有方法。過去您可能需要編寫一些代碼，對public static final int進(jìn)行轉(zhuǎn)換，把它從數(shù)據(jù)庫類型轉(zhuǎn)換為JDBC URL。而現(xiàn)在則可以讓枚舉類型本身帶一個整理代碼的方法。下面就是一個例子，包括DatabaseType枚舉類型的抽象方法以及每個枚舉實(shí)例中提供的實(shí)現(xiàn)：
public enum DatabaseType {
ORACLE {
public String getJdbcUrl() {...}
},
MYSQL {
public String getJdbcUrl() {...}
};
public abstract String getJdbcUrl();
}
現(xiàn)在枚舉類型可以直接提供它的實(shí)用方法。例如：
DatabaseType dbType = ...;
String jdbcURL = dbType.getJdbcUrl();
要獲取URL，必須預(yù)先知道該實(shí)用方法在哪里。
可變參數(shù)(Vararg)
Log.log(String code, String... args)
協(xié)變返回
協(xié)變返回的基本用法是用于在已知一個實(shí)現(xiàn)的返回類型比API更具體的時候避免進(jìn)行類型強(qiáng)制轉(zhuǎn)換。在下面這個例子中，有一個返回Animal對象的Zoo接口。我們的實(shí)現(xiàn)返回一個AnimalImpl對象，但是在JDK 1.5之前，要返回一個Animal對象就必須聲明。:
public interface Zoo {
public Animal getAnimal();
}
public class ZooImpl implements Zoo {
public Animal getAnimal(){
return new AnimalImpl();
}
}
協(xié)變返回的使用替換了三個反模式：
- 直接字段訪問。為了規(guī)避API限制，一些實(shí)現(xiàn)把子類直接暴露為字段：
ZooImpl._animal
另一種形式是，在知道實(shí)現(xiàn)的實(shí)際上是特定的子類的情況下，在調(diào)用程序中執(zhí)行向下轉(zhuǎn)換：
((AnimalImpl)ZooImpl.getAnimal()).implMethod();
- 我看到的最后一種形式是一個具體的方法，該方法用來避免由一個完全不同的簽名所引發(fā)的問題：
ZooImpl._getAnimal();
這三種模式都有它們的問題和局限性。要么是不夠整潔，要么就是暴露了不必要的實(shí)現(xiàn)細(xì)節(jié)。
協(xié)變
協(xié)變返回模式就比較整潔、安全并且易于維護(hù)，它也不需要類型強(qiáng)制轉(zhuǎn)換或特定的方法或字段：
public AnimalImpl getAnimal(){
return new AnimalImpl();
}
使用結(jié)果：
ZooImpl.getAnimal().implMethod();
參考：http://www.linuxpk.com/43834.html