This chapter is from the book
This chapter is from the book
This chapter is from the book
10.5. Standard Annotations
Java SE defines a number of annotation interfaces in the java.lang, java.lang.annotation, and javax.annotation packages. Four of them are meta-annotations that describe the behavior of annotation interfaces. The others are regular annotations that you can use to annotate items in your source code. Table 10.2 shows these annotations. We’ll discuss them in detail in the following two sections.
Table 10.2. The Standard Annotations
|
Annotation Interface |
Applicable To |
Purpose |
|
Deprecated |
All |
Marks item as deprecated. |
|
SuppressWarnings |
All but packages and annotations |
Suppresses warnings of the given type. |
|
Override |
Methods |
Checks that this method overrides a superclass method. |
|
PostConstruct PreDestroy |
Methods |
The marked method should be invoked immediately after construction or before removal. |
|
Resource |
Classes, interfaces, methods, fields |
On a class or interface, marks it as a resource to be used elsewhere. On a method or field, marks it for “injection.” |
|
Resources |
Classes, interfaces |
Specifies an array of resources. |
|
Generated |
All |
Marks an item as source code that has been generated by a tool. |
|
Target |
Annotations |
Specifies the items to which this annotation can be applied. |
|
Retention |
Annotations |
Specifies how long this annotation is retained. |
|
Documented |
Annotations |
Specifies that this annotation should be included in the documentation of annotated items. |
|
Inherited |
Annotations |
Specifies that this annotation, when applied to a class, is automatically inherited by its subclasses. |
10.5.1. Annotations for Compilation
The @Deprecated annotation can be attached to any items for which use is no longer encouraged. The compiler will warn when you use a deprecated item. This annotation has the same role as the @deprecated Javadoc tag.
The @SuppressWarnings annotation tells the compiler to suppress warnings of a particular type, for example,
@SuppressWarnings("unchecked")
The @Override annotation applies only to methods. The compiler checks that a method with this annotation really overrides a method from the superclass. For example, if you declare
public MyClass
{
@Override public boolean equals(MyClass other);
. . .
}
then the compiler will report an error. After all, the equals method does not over-ride the equals method of the Object class because that method has a parameter of type Object, not MyClass.
The @Generated annotation is intended for use by code generator tools. Any generated source code can be annotated to differentiate it from programmer-provided code. For example, a code editor can hide the generated code, or a code generator can remove older versions of generated code. Each annotation must contain a unique identifier for the code generator. A date string (in ISO 8601 format) and a comment string are optional. For example,
@Generated("com.horstmann.beanproperty", "2008-01-04T12:08:56.235-0700");
10.5.2. Annotations for Managing Resources
The @PostConstruct and @PreDestroy annotations are used in environments that control the lifecycle of objects, such as web containers and application servers. Methods tagged with these annotations should be invoked immediately after an object has been constructed or immediately before it is being removed.
The @Resource annotation is intended for resource injection. For example, consider a web application that accesses a database. Of course, the database access information should not be hardwired into the web application. Instead, the web container has some user interface for setting connection parameters and a JNDI name for a data source. In the web application, you can reference the data source like this:
@Resource(name="jdbc/mydb") private DataSource source;
When an object containing this field is constructed, the container “injects” a reference to the data source.
10.5.3. Meta-Annotations
The @Target meta-annotation is applied to an annotation, restricting the items to which the annotation applies. For example,
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface BugReport
Table 10.3 shows all possible values. They belong to the enumerated type ElementType. You can specify any number of element types, enclosed in braces.
Table 10.3. Element Types for the @Target Annotation
|
Element Type |
Annotation Applies To |
|
ANNOTATION_TYPE |
Annotation type declarations |
|
PACKAGE |
Packages |
|
TYPE |
Classes (including enum) and interfaces (including annotation types) |
|
METHOD |
Methods |
|
CONSTRUCTOR |
Constructors |
|
FIELD |
Fields (including enum constants) |
|
PARAMETER |
Method or constructor parameters |
|
LOCAL_VARIABLE |
Local variables |
An annotation without an @Target restriction can be applied to any item. The compiler checks that you apply an annotation only to a permitted item. For example, if you apply @BugReport to a field, a compile-time error results.
The @Retention meta-annotation specifies how long an annotation is retained. You can specify at most one of the values in Table 10.4. The default is RetentionPolicy.CLASS.
Table 10.4. Retention Policies for the @Retention Annotation
|
Retention Policy |
Description |
|
SOURCE |
Annotations are not included in class files. |
|
CLASS |
Annotations are included in class files, but the virtual machine need not load them. |
|
RUNTIME |
Annotations are included in class files and loaded by the virtual machine. They are available through the reflection API. |
In Listing 10.11 on p. 925, the @ActionListenerFor annotation was declared with RetentionPolicy.RUNTIME because we used reflection to process annotations. In the following two sections, you will see examples of processing annotations at the source and class file levels.
The @Documented meta-annotation gives a hint to documentation tools such as Javadoc. Documented annotations should be treated just like other modifiers such as protected or static for documentation purposes. The use of other annotations is not included in the documentation. For example, suppose we declare @ActionListenerFor as a documented annotation:
@Documented @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface ActionListenerFor
Now the documentation of each annotated method contains the annotation, as shown in Figure 10.2.
)
Figure 10.2. Documented annotations
If an annotation is transient (such as @BugReport), you should probably not document its use.
NOTE
It is legal to apply an annotation to itself. For example, the @Documented annotation is itself annotated as @Documented. Therefore, the Javadoc documentation for annotations shows whether they are documented.
The @Inherited meta-annotation applies only to annotations for classes. When a class has an inherited annotation, then all of its subclasses automatically have the same annotation. This makes it easy to create annotations that work as marker interfaces, such as Serializable.
In fact, an annotation @Serializable would be more appropriate than the Serializable marker interface with no methods. A class is serializable because there is runtime support for reading and writing its fields, not because of any principles of object-oriented design. An annotation describes this fact better than does interface inheritance. Of course, the Serializable interface was created in JDK 1.1, long before annotations existed.
Suppose you define an inherited annotation @Persistent to indicate that objects of a class can be saved in a database. Then the subclasses of persistent classes are automatically annotated as persistent.
@Inherited @interface Persistent { }
@Persistent class Employee { . . . }
class Manager extends Employee { . . . } // also @Persistent
When the persistence mechanism searches for objects to store in the database, it will detect both Employee and Manager objects.