Effective Java

---

CHAPTER 6
ENUMS AND ANNOTATIONS
190
Most IDEs provide another reason to use the 
Override
annotation consis-
tently. If you enable the appropriate check, the IDE will generate a warning if you
have a method that doesn’t have an 
Override
annotation but does override a
superclass method. If you use the 
Override
annotation consistently, these warn-
ings will alert you to unintentional overriding. They complement the compiler’s
error messages, which alert you to unintentional failure to override. Between the
IDE and the compiler, you can be sure that you’re overriding methods everywhere
you want to and nowhere else.
The 
Override
annotation may be used on method declarations that override
declarations from interfaces as well as classes
. 
With the advent of default meth-
ods, it is good practice to use 
Override
on concrete implementations of interface
methods to ensure that the signature is correct. If you know that an interface does
not have default methods, you may choose to omit 
Override
annotations on
concrete implementations of interface methods to reduce clutter.
In an abstract class or an interface, however, it 
is
worth annotating 
all
methods
that you believe to override superclass or superinterface methods, whether con-
crete or abstract. For example, the 
Set
interface adds no new methods to the
Collection
interface, so it should include 
Override
annotations on all of its
method declarations to ensure that it does not accidentally add any new methods
to the 
Collection
interface.
In summary, the compiler can protect you from a great many errors if you use
the 
Override
annotation on every method declaration that you believe to override
a supertype declaration, with one exception. In concrete classes, you need not
annotate methods that you believe to override abstract method declarations
(though it is not harmful to do so).

---

ITEM 41: USE MARKER INTERFACES TO DEFINE TYPES
191