Java Reference
In-Depth Information
15.5. Retention Policies
Annotations can serve many different purposes and may be intended for
different readers. Most of the annotations you have seen are intended to
be read by programmers, or perhaps a development tool. Others, such
as @Deprecated , are intended for the compiler to read. In some cases a
tool may need to extract the annotations from a binary representation
of a class, such as to determine how an application should be deployed.
And sometimes annotations will need to be inspected at runtime.
Associated with every annotation type is a retention policy that de-
termines when the annotation can be accessed. This retention policy is
defined by the RetentionPolicy enum, and is controlled by the use of the
Retention meta-annotation. There are three retention policy values:
SOURCE Annotations exist only in the source file, and are discarded
by the compiler when producing a binary representation.
CLASS Annotations are preserved in the binary representation of the
class, but need not be available at runtime.
RUNTIME Annotations are preserved in the binary representation of
the class and must be available at runtime via the reflection mech-
anism.
The default retention policy is CLASS . Regardless of the retention policy,
annotations on local variables are never available in the binary repres-
entation or at runtime. There is no place to store the information in the
binary representation.
The reflection methods for accessing annotations at runtime are dis-
cussed in Section 16.2 on page 414 . In essence, for each annotated ele-
ment, the runtime system creates an object that implements the inter-
face defined by the annotation type. You get the values of the annotation
elements for that program element by invoking the corresponding meth-
od on that object.
 
Search WWH ::




Custom Search