來一點咖啡，准備好進入注解的世界。
注解一直是 Java 的一個非常重要的部分，它從 J2SE 5.0 開始就已經存在了。在我們的應用程序代碼中，經常看到 @Override 和 @Deprecated 這樣的注解。在本文中，我將討論注解到底是什么，為什么引入注解，它們是如何工作的，如何編寫自定義注解(有示例代碼)，注解的有效場景是什么，最后是注解和 ADF。這將是一個很長的帖子，所以來一點咖啡，准備好進入注解的世界。
1. 注解是什么?
用一個詞來可以解釋：注解即是元數據。元數據是關於數據的數據。所以注解是代碼的元數據。舉個例子，查看下面的代碼。
@Override
public String toString() {
return "This is String Representation of current object.";
}
我在以上代碼中重寫 toString() 方法時使用了 @Override 注解。即使我不使用 @Override，代碼仍然能夠正常工作，沒有任何問題。那么，這個注解的優點是什么？又代表了什么？@Override 告訴編譯器，此方法是一個重寫的方法(有關該方法的元數據)，如果父類中不存在此類方法，則引發編譯器錯誤(超類中沒有被覆蓋其的方法)。現在，如果我犯了一個排版錯誤，並使用方法名為 toStrring() {double r} 如果我沒有使用 @Override，我的代碼會成功地編譯和執行，但是結果將會與預期不同。現在，我們理解了注解是什么，閱讀正式的定義是很有用處的。
注解是一種特殊的 Java 構造，用於修飾類、方法、字段、參數、變量、構造函數或包。這是 JSR-175 選擇的提供元數據的工具。
2. 為什么引入注解？
在注解出現之前(甚至之后)，XML 被廣泛地用於元數據，但是，一部分特定的應用程序開發人員和架構師認為 XML 維護變得麻煩了。他們希望能夠通過某種方式與代碼緊密耦合，來代替 XML，因為 XML 與代碼非常松散地耦合(在某些情況下，幾乎是獨立的)。如果你在谷歌上搜索 “XML vs annotations”，你會發現很多有趣的爭論。有趣的一點是，XML配置是為了將配置從代碼中分離出來而引入的。最后兩種說法可能會在你的腦海中產生一些疑問，即這兩種說法都在創造一個循環，但兩者各有優缺點。讓我們試着用一個例子來理解。
假設您希望設置一些應用程序范圍的常量/參數。在這個場景中，XML將是一個更好的選擇，因為這與任何特定的代碼段無關。如果您希望將某些方法公開為服務，那么注解將是一個更好的選擇，因為它需要與該方法緊密耦合，並且該方法的開發人員必須知道這一點。
另一個重要因素是注解定義了在代碼中定義元數據的標准方法。在注解之前，人們還使用自己的方法來定義元數據。一些例子是使用標記接口、注解、臨時關鍵字等。每個開發人員都需要根據自己的方式來決定元數據，但是注解是標准化的東西。
如今，大多數框架都將XML和注解結合起來，充分利用兩者的優點。
3.注解如何工作以及如何編寫自定義注解
在開始解釋之前，我建議您下載這個注釋(AnnotationsSample.zip) 的示例代碼，並在您常用的 IDE 中保持打開，因為它將幫助您更好地理解下面的解釋。
編寫注解非常簡單。您可以將注解定義與接口定義進行比較。讓我們看兩個例子 — 一個是標准 @Override 第二個注解是自定義注解。@Todo:
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface Override {
}
似乎有些可疑之處 @Override 它沒有做任何事情 — 它只是檢查是否在父類中定義了一個方法。別驚訝，我不是在開玩笑。重寫注解的定義只有那么多代碼。這是需要理解的最重要的部分，我重申一遍：注解只是元數據，不包含任何業務邏輯。很難理解但卻是真的。如果注解不包含邏輯，那么一定有人在做一些事情，並且有人是這個注解元數據的消費者。注解只提供有關定義的屬性(類/方法/包/字段)的信息。消費者是一段代碼，它讀取這些信息，然后執行必要的邏輯。
當我們談論標准注解時，比如 @Override ， JVM 是使用者，它是在字節碼級別工作的。這是應用程序開發人員無法控制、也不能用於自定義注解的東西。因此，我們需要為我們自己的注解寫一些消費實例。
讓我們逐一理解用於編寫注解的關鍵術語。在上面的例子中，您將看到注解如何被應用。
J2SE 5.0 在 java.lang.annotation 包中提供了四個注解，它們僅在編寫注解時使用：
@Documented – 是否將注解放在 Javadocs 中
@Retention – 注解什么時候被保留
@Target? – 注解可以使用的地方
@Inherited – 子類是否可以繼承注解。
@Documented - 一個簡單的標記注解，它標識了是否將注解添加到 Javadoc 中。
@Retention - 定義應保留注解的時間。
RetentionPolicy.SOURCE 在編譯期間丟棄。這些注解在編譯完成后沒有任何意義，因此它們不會被寫入字節碼。例子：@Override, @SuppressWarnings
RetentionPolicy.CLASS – 在類加載期間丟棄。應用在進行字節碼級別的編譯期間。有些令人驚訝的是，這是默認的。
RetentionPolicy.RUNTIME – 不會丟棄。該注解可以在運行時進行反射。這是我們通常用於自定義注解的內容。
@Target - 注解可以使用的地方。如果不指定這一屬性，注解可以應用在任何地方。以下是該注解的有效值。這里的一個要點，它只有包含的形式，這意味着如果您想要對7個屬性進行注解，並且只想排除一個屬性，這時需要在定義目標時包含所有7個屬性。
ElementType.TYPE (類，接口，枚舉)
ElementType.FIELD (實例變量)
ElementType.METHOD
ElementType.PARAMETER
ElementType.CONSTRUCTOR
ElementType.LOCAL_VARIABLE
ElementType.ANNOTATION_TYPE (用於其他注解)
ElementType.PACKAGE (記住 package-info.java)
@Inherited - 控制注解是否應該影響子類。
現在，注解定義中包含了什么？注解只支持基本類型、字符串和枚舉。注解的所有屬性都定義為方法，並且還可以提供默認值。
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@interface Todo {
public enum Priority {LOW, MEDIUM, HIGH}
public enum Status {STARTED, NOT_STARTED}
String author() default "Yash";
Priority priority() default Priority.LOW;
Status status() default Status.NOT_STARTED;
}
以下是如何使用上述注解的示例：
@Todo(priority = Todo.Priority.MEDIUM, author = "Yashwant", status = Todo.Status.STARTED)
public void incompleteMethod1() {
//Some business logic is written
//But it’s not complete yet
}
如果注解中只有一個屬性，則應該將其命名為 “value”，並且可以在使用時不使用屬性名稱。
@interface Author{
String value();
}
@Author("Yashwant")
public void someMethod() {
}
目前為止一切順利。我們已經定義了自定義注解，並將其應用於一些業務邏輯方法。現在，是時候寫一個消費的實例了。為了完成這個目標，我們需要使用到反射。如果您熟悉反射代碼，那么您就知道反射提供了類、方法和字段對象。所有這些對象都有一個 getAnnotation() 方法，該方法返回注解對象。我們需要將此對象轉換為自定義注解(在使用 instanceOf() 檢查之后)，然后，我們可以調用自定義注解中定義的方法。讓我們看一下示例代碼，它使用了上面的注解：
Class businessLogicClass = BusinessLogic.class;
for(Method method : businessLogicClass.getMethods()) {
Todo todoAnnotation = (Todo)method.getAnnotation(Todo.class);
if(todoAnnotation != null) {
System.out.println(" Method Name : " + method.getName());
System.out.println(" Author : " + todoAnnotation.author());
System.out.println(" Priority : " + todoAnnotation.priority());
System.out.println(" Status : " + todoAnnotation.status());
}
}
4. 注解用例
注解非常的強大，Spring 和 Hibernate 等框架非常廣泛地使用注解進行日志記錄和驗證。注解可以在使用標記接口的地方使用。標記接口用於整個類，但您可以定義可以用於單個方法的注解，例如，某個方法是否公開為服務方法。
在 servlet 3.0 規范中，引入了許多注解，特別是與 servlet 安全有關的注解。我們先來看看幾個：
HandlesTypes - 此注解用於聲明傳遞給 ServletContainerInitializer 的應用程序類數組。
HttpConstraint - 此注解表示應用於所有具有HTTP協議方法類型的請求的安全約束，在 ServletSecurity 上沒有相應的 HttpMethodConstraint 注解時。
HttpMethodConstraint - 特定的安全約束可以應用於不同類型的請求，在 ServletSecurity 上注解。
MultipartConfig - 此注解用於指示聲明它的 servlet 將使用 multiPart/form-Data MIME 類型發出請求。
ServletSecurity - 在 servlet 實現類上聲明此注解，對HTTP協議請求執行安全約束。
WebFilter - 用於聲明 servlet 過濾器的注解。
WebInitParam - 用於在 servlet 或過濾器上聲明初始化參數的注解，在 WebFilter 或 WebServlet 上注解。
WebListener - 用於在給定的Web應用程序上下文中聲明各種類型事件的偵聽器的注解。
WebServlet - 此注解用於聲明 servlet 的配置。
5. 應用程序開發框架(ADF，Application Development Framework)和注解
現在，我們正在討論的最后一部分：應用程序開發框架（ADF）。ADF 由 Oracle 開發，用於構建 Oracle 融合應用程序。我們已經看到了優點和缺點，並且知道如何編寫自定義注解，但是在 ADF 中我們可以在哪里使用自定義注解呢？ADF 是否提供本地注解？
這些無疑是有趣的問題：但是是否存在某些限制來阻止在 ADF 中大規模使用注解？前面提到的框架(如 Spring 和 Hibernate ) 使用的 AOP (面向方面的編程)。在 AOP 中，框架提供了為任何事件的預處理和后處理注入代碼的機制。例如，您有一個鈎子在方法執行之前和之后放置代碼，因此您可以在這些地方編寫自定義代碼。ADF 不使用 AOP。如果我們有任何有效的注解用例，我們可能需要通過繼承方式。
原文：https://dzone.com/videos/devnexus2015/how-annotations-work-java
譯者：遺失的拂曉