• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

@Overrides blues

 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hm.
Perhaps it makes more sense for javadocs, which the inventors thought of?
Just guessing.

And just to be sure: You tested whether eclipses refactoring-options might help better?
Perhaps you know eclipse better than me - then sorry.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic