Should a method that implements an interface method be annotated with @Override?
The javadoc of the Override annotation says:
Indicates that a method declaration is intended to override a method declaration in a superclass. If a method is annotated with this annotation type but does not override a superclass method, compilers are required to generate an error message.
I don't think that an interface is technically a superclass. Or is it?
This question is related to
java
oop
interface
annotations
For me, often times this is the only reason some code requires Java 6 to compile. Not sure if it's worth it.
For the interface, using @Override caused compile error. So, I had to remove it.
Error message went "The method getAllProducts() of type InMemoryProductRepository must override a superclass method".
It also read "One quick fix available: Remove @Override annotation."
It was on Eclipse 4.6.3, JDK 1.8.0_144.
If the class that is implementing the interface is an abstract class, @Override is useful to ensure that the implementation is for an interface method; without the @Override an abstract class would just compile fine even if the implementation method signature does not match the method declared in the interface; the mismatched interface method would remain as unimplemented.
The Java doc cited by @Zhao
The method does override or implement a method declared in a supertype
is clearly referring to an abstract super class; an interface can not be called the supertype.
So, @Override is redundant and not sensible for interface method implementations in concrete classes.
Eclipse itself will add the @Override annotation when you tell it to "generate unimplemented methods" during creation of a class that implements an interface.
You should always annotate methods with @Override if it's available.
In JDK 5 this means overriding methods of superclasses, in JDK 6, and 7 it means overriding methods of superclasses, and implementing methods of interfaces. The reason, as mentioned previously, is it allows the compiler to catch errors where you think you are overriding (or implementing) a method, but are actually defining a new method (different signature).
The equals(Object) vs. equals(YourObject) example is a standard case in point, but the same argument can be made for interface implementations.
I'd imagine the reason it's not mandatory to annotate implementing methods of interfaces is that JDK 5 flagged this as a compile error. If JDK 6 made this annotation mandatory, it would break backwards compatibility.
I am not an Eclipse user, but in other IDEs (IntelliJ), the @Override annotation is only added when implementing interface methods if the project is set as a JDK 6+ project. I would imagine that Eclipse is similar.
However, I would have preferred to see a different annotation for this usage, maybe an @Implements annotation.
Eclipse itself will add the @Override annotation when you tell it to "generate unimplemented methods" during creation of a class that implements an interface.
In java 6 and later versions, you can use @Override for a method implementing an interface.
But, I donot think it make sense: override means you hava a method in the super class, and you are implementing it in the sub class.
If you are implementing an interface, I think we should use @Implement or something else, but not the @Override.
I would use it at every opportunity. See When do you use Java's @Override annotation and why?
I believe that javac behaviour has changed - with 1.5 it prohibited the annotation, with 1.6 it doesn't. The annotation provides an extra compile-time check, so if you're using 1.6 I'd go for it.
Eclipse itself will add the @Override annotation when you tell it to "generate unimplemented methods" during creation of a class that implements an interface.
It's not a problem with JDK. In Eclipse Helios, it allows the @Override annotation for implemented interface methods, whichever JDK 5 or 6. As for Eclipse Galileo, the @Override annotation is not allowed, whichever JDK 5 or 6.
I believe that javac behaviour has changed - with 1.5 it prohibited the annotation, with 1.6 it doesn't. The annotation provides an extra compile-time check, so if you're using 1.6 I'd go for it.
I would use it at every opportunity. See When do you use Java's @Override annotation and why?
The problem with including the @Override is that it makes you think that you forgot to call the super.theOverridenMethod() method, which is very confusing. This should be crystal-clear. Perhaps Java should offer an @Interface to be used here. Oh well, yet another half-assed Java peculiarity...
I would use it at every opportunity. See When do you use Java's @Override annotation and why?
JDK 5.0 does not allow you to use @Override annotation if you are implementing method declared in interface (its compilation error), but JDK 6.0 allows it. So may be you can configure your project preference according to your requirement.
Overriding your own methods inherited from your own classes will typically not break on refactorings using an ide. But if you override a method inherited from a library it is recommended to use it. If you dont, you will often get no error on a later library change, but a well hidden bug.
JDK 5.0 does not allow you to use @Override annotation if you are implementing method declared in interface (its compilation error), but JDK 6.0 allows it. So may be you can configure your project preference according to your requirement.
For me, often times this is the only reason some code requires Java 6 to compile. Not sure if it's worth it.
You should always annotate methods with @Override if it's available.
In JDK 5 this means overriding methods of superclasses, in JDK 6, and 7 it means overriding methods of superclasses, and implementing methods of interfaces. The reason, as mentioned previously, is it allows the compiler to catch errors where you think you are overriding (or implementing) a method, but are actually defining a new method (different signature).
The equals(Object) vs. equals(YourObject) example is a standard case in point, but the same argument can be made for interface implementations.
I'd imagine the reason it's not mandatory to annotate implementing methods of interfaces is that JDK 5 flagged this as a compile error. If JDK 6 made this annotation mandatory, it would break backwards compatibility.
I am not an Eclipse user, but in other IDEs (IntelliJ), the @Override annotation is only added when implementing interface methods if the project is set as a JDK 6+ project. I would imagine that Eclipse is similar.
However, I would have preferred to see a different annotation for this usage, maybe an @Implements annotation.
Overriding your own methods inherited from your own classes will typically not break on refactorings using an ide. But if you override a method inherited from a library it is recommended to use it. If you dont, you will often get no error on a later library change, but a well hidden bug.
If a concrete class is not overriding an abstract method, using @Override for implementation is an open matter since the compiler will invariably warn you of any unimplemented methods. In these cases, an argument can be made that it detracts from readability -- it is more things to read on your code and, to a lesser degree, it is called @Override and not @Implement.
By reading the javadoc in java8, you can find the following at the declaration of interface Override:
If a method is annotated with this annotation type compilers are required to generate an error message unless at least one of the following conditions hold:
So, at least in java8, you should use @Override on an implementation of an interface method.
Overriding your own methods inherited from your own classes will typically not break on refactorings using an ide. But if you override a method inherited from a library it is recommended to use it. If you dont, you will often get no error on a later library change, but a well hidden bug.
I believe that javac behaviour has changed - with 1.5 it prohibited the annotation, with 1.6 it doesn't. The annotation provides an extra compile-time check, so if you're using 1.6 I'd go for it.
For the interface, using @Override caused compile error. So, I had to remove it.
Error message went "The method getAllProducts() of type InMemoryProductRepository must override a superclass method".
It also read "One quick fix available: Remove @Override annotation."
It was on Eclipse 4.6.3, JDK 1.8.0_144.
By reading the javadoc in java8, you can find the following at the declaration of interface Override:
If a method is annotated with this annotation type compilers are required to generate an error message unless at least one of the following conditions hold:
So, at least in java8, you should use @Override on an implementation of an interface method.
Eclipse itself will add the @Override annotation when you tell it to "generate unimplemented methods" during creation of a class that implements an interface.
If a concrete class is not overriding an abstract method, using @Override for implementation is an open matter since the compiler will invariably warn you of any unimplemented methods. In these cases, an argument can be made that it detracts from readability -- it is more things to read on your code and, to a lesser degree, it is called @Override and not @Implement.
Overriding your own methods inherited from your own classes will typically not break on refactorings using an ide. But if you override a method inherited from a library it is recommended to use it. If you dont, you will often get no error on a later library change, but a well hidden bug.
The problem with including the @Override is that it makes you think that you forgot to call the super.theOverridenMethod() method, which is very confusing. This should be crystal-clear. Perhaps Java should offer an @Interface to be used here. Oh well, yet another half-assed Java peculiarity...
If the class that is implementing the interface is an abstract class, @Override is useful to ensure that the implementation is for an interface method; without the @Override an abstract class would just compile fine even if the implementation method signature does not match the method declared in the interface; the mismatched interface method would remain as unimplemented.
The Java doc cited by @Zhao
The method does override or implement a method declared in a supertype
is clearly referring to an abstract super class; an interface can not be called the supertype.
So, @Override is redundant and not sensible for interface method implementations in concrete classes.
I believe that javac behaviour has changed - with 1.5 it prohibited the annotation, with 1.6 it doesn't. The annotation provides an extra compile-time check, so if you're using 1.6 I'd go for it.
For me, often times this is the only reason some code requires Java 6 to compile. Not sure if it's worth it.
For me, often times this is the only reason some code requires Java 6 to compile. Not sure if it's worth it.
It's not a problem with JDK. In Eclipse Helios, it allows the @Override annotation for implemented interface methods, whichever JDK 5 or 6. As for Eclipse Galileo, the @Override annotation is not allowed, whichever JDK 5 or 6.
Source: Stackoverflow.com