注釈を使用できる主な分野は何ですか?この機能は、XMLベースの構成に代わるものですか?
注釈はメタメタオブジェクトで、他のメタオブジェクトを記述するために使用できます。メタオブジェクトは、クラス、フィールド、およびメソッドです。オブジェクトにメタオブジェクト(たとえば、anObj.getClass()
)を要求することは、introspectionと呼ばれます。イントロスペクションはさらに進むことができ、メタオブジェクトにその注釈を尋ねることができます(例:aClass.getAnnotations
)。イントロスペクションと注釈は、reflectionおよびmeta-programmingと呼ばれるものに属します。
注釈は、何らかの方法で解釈して有用である必要があります。注釈は、development-timeでIDEまたはコンパイラによって、またはrun-timeで解釈できます。フレームワークによって。
注釈処理は非常に強力なメカニズムであり、さまざまな方法で使用できます。
@Deprecated, @Override
、または@NotNull
@Entity, @TestCase, @WebService
@Statefull, @Transaction
@Column, @XmlElement
すべての場合において、注釈を使用して要素をdescribeし、そのの意味を明確にします。
JDK5より前は、アノテーションで表現される情報は別の場所に保存する必要があり、XMLファイルが頻繁に使用されていました。ただし、注釈はJavaコード自体に属するため、XMLよりも操作がはるかに簡単なので、注釈を使用する方が便利です。
注釈の使用法:
...プロジェクトをご覧ください Lombok 。これは、注釈を使用してequals
またはhashCode
メソッドを生成する方法を定義します。
Javaのアノテーションには複数のアプリケーションがあります。まず、コンパイラー(またはコンパイラー拡張機能)で使用される場合があります。たとえば、Override注釈を検討してください。
class Foo {
@Override public boolean equals(Object other) {
return ...;
}
}
これは実際にはJava JDKに組み込まれています。コンパイラは、何らかのメソッドにタグが付けられている場合、エラーを通知します。これは、基本クラスから継承されたメソッドをnotオーバーライドします。このアノテーションは、メソッドを実際にオーバーライドしようとする一般的な間違いを避けるために役立ちますが、メソッドで指定された署名がオーバーライドされるメソッドの署名と一致しないため、失敗します。
class Foo {
@Override public boolean equals(Foo other) { // Compiler signals an error for this one
return ...;
}
}
近日リリースされるJDK7では、あらゆるタイプの注釈が許可されます。次のように、NotNullなどのコンパイラ注釈にこの機能を使用する提案が既にあります。
public void processSomething(@NotNull String text) {
...
}
これにより、コンパイラーは、変数およびnull値の不適切/未チェックの使用について警告することができます。
別のより高度な注釈のアプリケーションには、実行時のリフレクションと注釈処理が含まれます。これは、注釈を「XMLベースの構成の置換」と言うときに念頭に置いていたものだと思います。これは、たとえば、必要なメタデータと構成情報を提供するために、さまざまなフレームワークとJCP標準(永続性、依存性注入、名前を付ける)で使用される注釈処理の一種です。
注釈は、Javaソースファイルに追加されるメタデータ(データに関するデータ)の形式です。クライアントコードの統合を簡素化するために、主にフレームワークで使用されます。私の頭の上のいくつかの実世界の例:
JUnit 4-JUnitランナーに実行させる各テストメソッドに@Test
注釈を追加します。テストの設定に関連する追加の注釈もあります(@Before
や@BeforeClass
など)。これらはすべてJUnitランナーによって処理され、JUnitランナーはそれに応じてテストを実行します。 XML構成の代わりと言えるかもしれませんが、注釈はより強力な場合があり(たとえば、リフレクションを使用できます)、参照しているコードに近くなります(@Test
注釈はテストの直前です)メソッド。そのため、そのメソッドの目的は明確です-ドキュメントとしても機能します)。一方、XML構成はより複雑になる可能性があり、注釈よりもはるかに多くのデータを含めることができます。
Terracotta-注釈とXML構成ファイルの両方を使用します。たとえば、@Root
注釈は、注釈付きフィールドがルートであり、そのメモリをVMインスタンス間で共有する必要があることをTerracottaランタイムに通知します。 XML構成ファイルは、サーバーを構成し、計測するクラスを伝えるために使用されます。
Google Guice-例は@Inject
アノテーションです。これをコンストラクターに適用すると、Guiceランタイムは定義済みのインジェクターに基づいて各パラメーターの値を検索します。 @Inject
アノテーションは、XML構成ファイルを使用して複製するのは非常に難しく、参照するコンストラクターに近接していることは非常に便利です(セットアップしたすべての依存関係注入を見つけるために巨大なXMLファイルを検索する必要があることを想像してください) )。
さまざまなフレームワークでアノテーションがどのように使用されるかについてのフレーバーをお届けできれば幸いです。
Javaの注釈は、クラス、フィールド、およびメソッドを記述する手段を提供します。基本的に、これらはJavaソースファイルに追加されるメタデータの形式であり、プログラムのセマンティクスに直接影響を与えることはできません。ただし、注釈は実行時にReflectionを使用して読み取ることができ、このプロセスはIntrospectionとして知られています。次に、クラス、フィールド、またはメソッドの変更に使用できます。
この機能は、ライブラリとSDK(hibernate、JUnit、Spring Framework)によって悪用されることが多く、これらのライブラリまたはSDKを使用するためにプログラマーが作業しない限り、コードの量を単純化または削減します。リフレクションは、Javaで手をつないで動作します。
また、注釈の可用性をコンパイル時またはランタイムのいずれかに制限することもできます。以下は、カスタム注釈の作成に関する簡単な例です
Driver.Java
package io.hamzeen;
import Java.lang.annotation.Annotation;
public class Driver {
public static void main(String[] args) {
Class<TestAlpha> obj = TestAlpha.class;
if (obj.isAnnotationPresent(IssueInfo.class)) {
Annotation annotation = obj.getAnnotation(IssueInfo.class);
IssueInfo testerInfo = (IssueInfo) annotation;
System.out.printf("%nType: %s", testerInfo.type());
System.out.printf("%nReporter: %s", testerInfo.reporter());
System.out.printf("%nCreated On: %s%n%n",
testerInfo.created());
}
}
}
TestAlpha.Java
package io.hamzeen;
import io.hamzeen.IssueInfo;
import io.hamzeen.IssueInfo.Type;
@IssueInfo(type = Type.IMPROVEMENT, reporter = "Hamzeen. H.")
public class TestAlpha {
}
IssueInfo.Java
package io.hamzeen;
import Java.lang.annotation.ElementType;
import Java.lang.annotation.Retention;
import Java.lang.annotation.RetentionPolicy;
import Java.lang.annotation.Target;
/**
* @author Hamzeen. H.
* @created 10/01/2015
*
* IssueInfo annotation definition
*/
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface IssueInfo {
public enum Type {
BUG, IMPROVEMENT, FEATURE
}
Type type() default Type.BUG;
String reporter() default "Vimesh";
String created() default "10/01/2015";
}
注釈には2つのビューがあります
ユーザービュー、ほとんどの場合、注釈はショートカットのように機能し、キーストロークを節約したり、プログラムを読みやすくしたりします
ベンダーのビュー、プロセッサの注釈のビューはより軽量な「インターフェース」であり、プログラムは特定のインターフェースを明示的に「実装」せずに何かに直面します(ここでは別名)
例えばJPAでは、次のように定義します
@Entity class Foo {...}
の代わりに
class Foo implements Entity {...}
両方が同じことを話します「FooはEntityクラスです」
XMLベースの構成に代わるものですか?
完全ではありませんが、コード構造(SpringでのJPAマッピングや依存性注入など)に密接に対応する構成は、多くの場合、注釈に置き換えることができ、通常はそれほど冗長ではなく、面倒で苦痛です。ほとんどすべての注目すべきフレームワークがこの切り替えを行いましたが、通常、古いXML構成はオプションとして残ります。
注釈は宣言に適用できます:クラス、フィールド、メソッド、その他のプログラム要素の宣言。宣言で使用される場合、各注釈は通常、慣例により独自の行に表示されます。
Java SE 8 Update:注釈は、型の使用にも適用できます。ここではいくつかの例を示します。
クラスインスタンス作成式:
新しい@Interned MyObject();
型キャスト:
myString =(@NonNull String)str;
implements句:
クラスUnmodifiableListは@Readonly List <@Readonly T> {...}を実装します
スローされた例外宣言:
void monitorTemperature()throws @Critical TemperatureException {...}
Hibernateのようなフレームワークでは、多くの構成/マッピングが必要でしたが、アノテーションを多用しています。
Hibernate Annotations をご覧ください
JPA(Java EE 5から)は、アノテーションの(過剰な)使用の優れた例です。 Java EE 6は、RESTful Webサービスや、古き良きサーブレットAPIごとの新しい注釈など、多くの新しい領域に注釈を導入します。
以下にいくつかのリソースを示します。
アノテーションによって引き継がれる/できるのは構成の詳細だけではなく、動作を制御するためにも使用できます。これはJava EE 6のJAX-RSの例に見られます。
メソッド、クラス、またはフィールドレベルのいずれかで、クラスに注釈を付けるのに役立ちます。そのクラスについては、クラスにあまり関係していません。
特定のクラスをテスト専用としてマークするために使用する独自の注釈を付けることもできます。それは単に文書化の目的である場合もあれば、実動リリース候補のコンパイル中にフィルターで除外することで強制することもできます。
プラグインのフレームワークなど、プラグインの名前などのメタデータを保存するために注釈を使用できます。
単なる別のツールであり、多くの目的があります。
(a)コンパイラーチェックまたは(b)コード分析により、コードに関する追加情報を添付します。
**
**
タイプ1)Javaコードに適用される注釈:
@Override // gives error if signature is wrong while overriding.
Public boolean equals (Object Obj)
@Deprecated // indicates the deprecated method
Public doSomething()....
@SuppressWarnings() // stops the warnings from printing while compiling.
SuppressWarnings({"unchecked","fallthrough"})
タイプ2)他の注釈に適用される注釈:
@Retention - Specifies how the marked annotation is stored—Whether in code only, compiled into the class, or available at run-time through reflection.
@Documented - Marks another annotation for inclusion in the documentation.
@Target - Marks another annotation to restrict what kind of Java elements the annotation may be applied to
@Inherited - Marks another annotation to be inherited to subclasses of annotated class (by default annotations are not inherited to subclasses).
**
** http://en.wikipedia.org/wiki/Java_annotation#Custom_annotations
より良い理解のために以下のリンクを試してください:例を挙げて詳しく説明してください
Java注釈の目的は、注釈付きプログラム要素に情報を関連付けることです。 Java注釈は、パッケージ、クラス(列挙型を含む)、インターフェイス(注釈型を含む)、フィールド、メソッド、仮パラメーター、コンストラクター、ローカル変数など、宣言の修飾子として使用できます。
Javaアノテーションは、enum定数でも使用できます。このような注釈は、注釈を付ける列挙定数の直前に配置されます。 Java注釈は従来、他のすべての修飾子の前に配置されますが、これは要件ではありません。それらは、他の修飾子と自由に混在させることができます。
Java Annotations の詳細をお読みください。
Java EE 5は、XML構成よりも注釈の使用を好みます。たとえば、EJB3では、EJBメソッドのトランザクション属性はアノテーションを使用して指定されます。さらに、アノテーションを使用してPOJOをEJBとしてマークし、インターフェイスの実装を要求する代わりに、特定のメソッドをライフサイクルメソッドとして指定します。
注釈は外部構成ファイルの代替として使用できますが、完全な代替と見なすことはできません。 Hibernate、JPA、EJB 3、およびJava EEに含まれるほぼすべてのテクノロジーなど、アノテーションが構成ファイルを置き換えるために使用された多くの例を見つけることができます。
とにかく、これは常に良い選択ではありません。構成ファイルを使用する目的は、通常、アプリケーションを実行している環境の詳細からコードを分離することです。このような状況では、主に構成を使用してアプリケーションを外部システムの構造にマッピングする場合、注釈は構成ファイルの適切な代替ではありません。外部システムの詳細をあなたの申請。ここでは、外部ファイルが最良の選択と見なされます。そうでない場合は、実行環境で関連する詳細を変更するたびにソースコードを変更し、再コンパイルする必要があります。
注釈は、コンパイル時と実行時の両方で処理ツールに特別な方法でクラスとクラス構造を処理するよう指示する追加情報でソースコードを修飾するのに適しています。 @Override
とJUnitの@Test
はそのような使用法の良い例であり、すでに他の回答で詳細に説明されています。
最終的に、ルールは常に同じです。ソース内でソースとともに変化するものを保持し、ソース外でソースから独立して変化するものを保持します。