Java Reference
In-Depth Information
15.6. Working with Annotations
Annotations can be very powerful, but they can easily be misused. It
is easy to achieve annotation-overload when the number and verbosity
of the annotations totally obscure the code itself. Annotations should be
used sparingly and wisely.
The second problem with annotations is that anyone can define their
own. A key benefit of annotations is their suitability for automatic analys-
is, generally via annotation processing tools, or
APTs
. But automation is
most helpful if there are common, standard annotations. While you have
seen how annotation types can be defined, in practice very few program-
mers should need to define their own types. There are currently only a
few defined annotation types:
[4]
[4]
Under the Java Community Process,
JSR
250 is defining common annotations for future use.
•
The meta-annotations
@Target
and
@Retention
, which you have
seen.
•
The
@Deprecated
and
@Documented
annotations, which you have also
seen.
•
The
@Inherited
meta-annotation that indicates an annotation
should be inherited. For example, if a class
Foo
is queried for a spe-
cific annotation type that is not present on
Foo
, but that annotation
type has the
@Inherited
meta-annotation, then
Foo
's superclass will
be queried, and so forth.
•
The
@Override
annotation, which informs the compiler that a meth-
od is meant to override an inherited method from a superclass.
This allows the compiler to warn you if you mistakenly overload
the method instead of overriding it (a common mistake).
•
The
@SuppressWarnings
annotation tells the compiler to ignore cer-
tain warnings, as defined by the strings used to initialize the
annotation. Unfortunately, there is no predefined set of warning
