Thursday, November 22, 2007

Why Override Annotation is Cool

Since Java5 which brought us annotations, Java has had the @Override annotation. But I don't see it used very often, so here I will try and explain why I find it valuable.

When you write a POJO like this:
public class Person {
private String name;


public String tostring() {
return "Person[" + name + "]";
Where the intention of the tostring() method was to override the Object#toString() method, you might be surprised when your method is not called. In this example, it was due to a simple case error ("tostring()" and not "toString()"), but in other scenarios, the error can be hidden somewhere else in a more complex method signature.

Had you been putting a @Override annotation on top of the method signature, you would have gotten a compiler error (or quite possibly already in the IDE). So the @Override annotation says that the annotated method must fulfill the contract of a method up in the class hierarchy. That is the valuable part of the override annotation :-)

Eclipse and IDEA
Last time I tried Eclipse, it played nice and automatically put the annotation on methods, when I used Eclipse keyboard shortcuts to introduce an override. This was on by default. It is not in IDEA :-( But is is very simple to add. Notice the little checkmark "Insert @Override" in the dialog that Ctrl-O opens? Check it, and it will be checked by default from here on.

C# Has It Built-In
The C# language of .Net has a override keyword as a part of language itself. In the C# language you are forced to use the keyword, which is okay by me, as I like it. What I really do not like then, is the virtual keyword of C#. I much better like that all methods are virtual in Java. But that is another story...


Anonymous said... know, IntelliJ and Eclipse both have an arrow icon showing you it's an override. True that if you are class through a non modern ide or text editor, it won't tell you. But because the most popular java ide's already tell you...i would say it's not that cool.

Steve Chaloner said...

Using the IDE to indicate inheritence is fine if you can guarantee 100% of the time the code will only ever be accessed through an IDE by every person who will edit it. Who knows, the next release of your favourite IDE may scrap inheritence indicator icons for whatever reason!

Using annotations allows you to declare your intentions from the casual reader through to the compiler.

Alex said...

As a side node, the reason C# has the "virtual" and "override" keyword is because to get a performance boost on the dynamic method dispatch. If a method is not virtual, the C# runtime does not need to spend the time looking for other implemnentations like the JVM must do on every method call.

Per Olesen said...

@Alex: About performance and virtual/override. Yes. And I believe there has been criticism of this on Java back in the old days with the not so evolved VM. That was back in Java 1.1 og Java2, and people where using the "final" keyword in Java, to get "better" performance (that's like a non-virtual function).

But, with the entry of the hotspot VM (which is SOME time ago now :-), this changed. Suddenly, the advice on using final to get better performance became an anti-pattern. A don't do it. The hotspot VM can analyze a lot of the situations, to make the decision, that a call does not have other implementations.

yagmurunsesi said...