Java Override annotation

Using the @Override annotation acts as a compile-time safeguard against a common programming mistake. It willthrow a compilation error if you have the annotation on a method you’re not actually overriding the superclass method.
The most common case where this is useful is when you are changing a method in the base class to have a different parameter list. A method in a subclass that used to override the superclass method will no longer do so due the changed method signature. This can sometimes cause strange and unexpected behavior, especially when dealing with complex inheritance structures. The @Override annotation safeguards against this.
To take advantage from compiler checking you should always use Override annotation. But don’t forget that Java Compiler 1.5 will not allow this annotation when overriding interface methods. You just can use it to override class methods (abstract, or not).
Some IDEs, as Eclipse, even configured with Java 1.6 runtime or higher, they maintain compliance with Java 1.5. To avoid that behaviour you must go to: Project Properties ->Java Compiler -> Check “Enable Project Specific Settings” -> Choose “Compiler Compliance Level” = 6.0, or higher
Java’s @Override annotation follows when
  • • Used only on method declarations.
  • • Indicates that the annotated method declaration overrides a declaration in supertype.
If used consistently, it protects you from a large class of nefarious bugs.
Use @Override annotation to avoid these bugs: (Spot the bug in the following code:)
public class Bigram {
private final char first;
private final char second;
public Bigram(char first, char second) {
this.first = first;
this.second = second;
}





public boolean equals(Bigram b) {
return b.first == first && b.second == second;
}
public int hashCode() {
return 31 * first + second;
}
public static void main(String[] args) {
Set<Bigram> s = new HashSet<Bigram>();
for (int i = 0; i < 10; i++)
for (char ch = ‘a’; ch <= ‘z’; ch++)
s.add(new Bigram(ch, ch));
System.out.println(s.size());
}
}
The main program repeatedly adds twenty-six bigrams, each consisting of two identical lowercase letters, to a set. Then it prints the size of the set. You might expect the program to print 26, as sets cannot contain duplicates. If you try running the program, you’ll find that it prints not 26 but 260. What is wrong with it?
Clearly, the author of the Bigram class intended to override the equals method (Item-8) and even remembered to override hashCode in tandem (Item-9 )
Unfortunately, our hapless programmer failed to override equals, overloading it instead (Item-41) To override Object.equals, you must define an equals method whose parameter is of type Object, but the parameter of Bigram’s equals method is not of type Object, so Bigram inherits the equals method from
Object. This equals method tests for object identity, just like the == operator.
Each of the ten copies of each bigram is distinct from the other nine, so they are deemed unequal by Object.equals, which explains why the program prints 260.
Luckily, the compiler can help you find this error, but only if you help the compiler by telling it that you intend to override Object.equals. To do this,
annotate Bigram.equals with @Override, as shown below:
@Override public boolean equals(Bigram b) {
return b.first == first && b.second == second;
}
If you insert this annotation and try to recompile the program, the compiler will generate an error message like this:
Bigram.java:10: method does not override or implement a method from a supertype
@Override public boolean equals(Bigram b) {
^
You will immediately realize what you did wrong, slap yourself on the forehead, and replace the broken equals implementation with a correct one (Item 8):
@Override public boolean equals(Object o) {
if (!(o instanceof Bigram))
return false;
Bigram b = (Bigram) o;
return b.first == first && b.second == second;
}
NOTE : Item 8 , Item 9, Item 41 mentioned are part of Effective Java by Joshua Bloch
Therefore, you should use the Override annotation on every method declaration that you believe to override a superclass declaration.
Using the @Overri
de annotation acts as a compile-time safeguard against a common programming mistake. It will throw a compilation error if you have the annotation on a method you’re not actually overriding the superclass method.

0 comments:

Post a Comment