I usually add @Override to methods which override super class methods since Eclipse issues a warning about its absence. It seems like a reasonable thing to have in place and I've always assumed that if Eclipse warns about its absence then it must have some good reason for being there. I like it because its a good indicator right in the code which eliminates me having to look into super classes to see if there is another method implementation. However I have recently become aware that in Java 1.6 it no longer has the original meaning of "this method overrides a method already implemented in a super class" (at least that was always my understanding), and now I've read somewhere that it has additional meanings attached to it related to the method being an implementation of a method from the interface (it seems like an @Implementation annotation or something similar would be more accurate in this case), but it's not clear from the API what the actual updated meaning of @Override really is.
What made me start thinking about this is that NetBeans will expect @Override on any method which implements a method declared in the interface of the class, and in my opinion that's not an override but a normal implementation which shouldn't take an @Override. Eclipse doesn't seem to do this, and only warns you when a truly overriding method is not annotated as such, which is what I expect. Of course you can eliminate the warnings about @Override altogether but I like the warnings since I want to have the annotations in my code, I just want to be using them correctly.
Does anyone know more about this than I do? Please enlighten me if so. Thanks in advance for your insight!
I was under the impression that Java 6 let you apply the tag to methods coming from an interface too. Similarly the meaning would evolve.
It would be a similar meaning - this method overrides the declaration. As opposed to - this method overrides another implementation. It's optional of course.
I like the idea of putting them there for interface methods though for the same reason as abstract methods. If the interface changes, my IDE can tell me that I am no longer overriding the method I think I am.
Thanks Jeanne. At first I was thinking that it's a bad thing to mix the meaning of an override and an implementation into a single annotation, but I can get used to it. I'm starting to see how it's helpful to have @Override on a method which implements a method from the classes' interface, since if the method is removed from the interface then you will get a warning or error from the IDE telling you that the method is no longer an implementation of an interface method. Without the @Override annotation you could remove the method from the interface and still have the implementation hanging around in the class where it probably is never used, and if it is you have to remove the @Override, making you pay a little more attention to what you're doing.