This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
The team I'm working with has to maintain a *big* code base, and refactor it mercilessly. Now and then a method gets renamed or removed that is overriden in subclasses without us noticing it. It's a problem that doesn't occur often, but when it does, it's rather hard to debug.
So when we read about the Overrides annotation in Tiger, we rejoiced - it was exactly the feature we were waiting for! Now "all" we had to do is convince all our customer to switch to a JRE 1.5...
Until I read http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5008260 - it doesn't work the way we thought it would. Specifically, it only works for methods you inherit that already have an implementation. If you implement an abstract method, putting the override annotation at the implementation will give a compile time error.
What were they thinking? What is such a crippled feature good for? I don't get it.
If anyone can make sense out of that, please tell me...
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
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.
If somebody makes the same change to a concrete superclass method, then you'll see the bugs you speak of, and that's the case that @Override protects you from. 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.
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.
author and iconoclast
I agree with you that on the face of it, it seems like an unnecessary restriction. It reminds me, actually, of one of my favorite annoyances: why can't dynamic proxies extend classes, rather than just implementing an interface? I'm sure you've had the same thought -- sure would be handy for testing.
Personally, I think the way the entire annotations concept was introduced into the language is dreadful. There is no reason whatsoever why they couldn't have just used Javadoc tags, and thereby not broken every Java-aware editor in creation. Introducing so much new, un-Javalike syntax is just unneeded complexity. And as you're feeling, the definitions of the standard annotations aren't very intuitive.