Originally posted by Ernest Friedman-Hill:
The difference is that if somebody renames a method in an interface, or changes the parameter list, or similarly does the same with an abstract method, your code will no longer compile, because you're no longer implementing the abstract method. Therefore, @Overrides isn't really needed in that case.
Well, ok, probably not for changing the method signature (unless you change it to one that also already exists in the subclass, probably a rare case, though).
It would be a nice tool to find dead code when a method gets removed from an interface, though.
I also don't understand what harm it would have done. I actually expect it to be rather annoying to get a compiler error when you remove a default implementation from a base class and subclasses don't any longer override it but "only" implement the one from the interface.
Note that neither the annotation nor the compile error will help you if the superclass or interface changes but your overriding class isn't recompiled.
Noted.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus