Home > Articles

  • Print
  • + Share This
This chapter is from the book

8.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 8.2 shows these annotations. We’ll discuss them in detail in the following two sections.

Table 8.2 The Standard Annotations

Annotation Interface

Applicable To




Marks item as deprecated.


All but packages
and annotations

Suppresses warnings of the given type.


Methods and

Asserts that the varargs parameter is safe
to use.



Checks that this method overrides a
superclass method.



Marks an interface as functional (with a
single abstract method).



The marked method should be invoked
immediately after construction or before


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.„


Classes, interfaces

Specifies an array of resources.



Marks an item as source code that has
been generated by a tool.



Specifies the items to which this
annotation can be applied.



Specifies how long this annotation is



Specifies that this annotation should be
included in the documentation of
annotated items.



Specifies that this annotation, when
applied to a class, is automatically
inherited by its subclasses.



Specifies that this annotation can be
applied multiple times to the same item.

8.5.1 Annotations for Compilation

The @Deprecated annotation can be attached to any items whose 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,


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 override 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");

8.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:

private DataSource source;

When an object containing this field is constructed, the container “injects” a reference to the data source.

8.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 8.3 shows all possible values. They belong to the enumerated type ElementType. You can specify any number of element types, enclosed in braces.

Table 8.3 Element Types for the @Target Annotation

Element Type

Annotation Applies To


Annotation type declarations




Classes (including enum) and interfaces (including annotation types)






Fields (including enum constants)


Method or constructor parameters


Local variables


Type parameters


Uses of a type

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 8.4. The default is RetentionPolicy.CLASS.

Table 8.4 Retention Policies for the @Retention Annotation

Retention Policy



Annotations are not included in class files.


Annotations are included in class files, but the virtual machine
need not load them.


Annotations are included in class files and loaded by the virtual
machine. They are available through the reflection API.

In Listing 8.11 on p. 461, 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:

public @interface ActionListenerFor

Now the documentation of each annotated method contains the annotation, as shown in Figure 8.2.

Figure 8.2

Figure 8.2 Documented annotations

If an annotation is transient (such as @BugReport), you should probably not document its use.

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.

As of Java SE 8, it is legal to apply the same annotation type multiple times to an item. For backward compatibility, the implementor of a repeatable annotation needs to provide a container annotation that holds the repeated annotations in an array.

Here is how to define the @TestCase annotation and its container:

@interface TestCase
   String params();
   String expected();

@interface TestCases
   TestCase[] value();

Whenever the user supplies two or more @TestCase annotations, they are automatically wrapped into a @TestCases annotation.

  • + Share This
  • 🔖 Save To Your Account