When I implement an Interface in Java, for instance:
public interface IColumnHeader {
public String getHeaderValue();
public String findColumnValueFromHeaderValue(String parseFrom);
}
the following enum implements the above interface:
public enum FileColumnDwellTime implements IColumnHeader {
REPORTER_USER_ID {
@Override
public String getHeaderValue() {
return "reporter_user_id";
}
@Override
public String findColumnValueFromHeaderValue(String parseFrom) {
return parseFrom;
}
};
}
Why does implementing an interface in Java and implementing the methods from the interface introduce the @Override annotation. Isn't that a total misnomer?
Shouldn't that annotation actually be called something like "@Implementation"?
The @Override annotation would be more apt for subclasses that actually override superclass methods that are predefined. In the case of simply implementing a method from an interface, there is no actual overriding being done.
Am I right?
(If I were the JLS writers for Java 9, I would have a new annotation called @Implementation that would "subclass" the @Override annotation, in the case of implementing methods from interfaces, and the like.)
Taking a look at the JLS, it just seems to be how it's defined. I'm looking at JLS 8, not sure if the section I'm going to quote was different in earlier versions (although I highly doubt it will, since interface interactions shouldn't have changed). From section 8.4.8.1:
An instance method mC declared in or inherited by class C, overrides from C another method mI declared in an interface I, iff all of the following are true:
- I is a superinterface of C.
- mI is an abstract or default method.
- The signature of mC is a subsignature (§8.4.2) of the signature of mI.
So at least based on this, the @Override
annotation makes sense, since it denotes an instance method that overrides a method declared in an interface, based on the definitions in the JLS.
Unfortunately, I can't give an authoritative answer as to why this is called overriding, but here's sort of how it works in my head:
If you inherit an abstract
method (like one in an interface), your class implicitly contains the signature for that method in its body. When you implement the method corresponding to that signature, you replace (and thus override) the inherited abstract method signature with one corresponding to a concrete implementation. So it makes sense to have @Override
, right?
In addition, this way @Override
would work for overridden methods regardless of whether they were technically an implementation or "truly" overridden. And why make more work for yourself (and compiler designers) than you have to?
I know that that's a rather bad view of how inheritance works, but I hope it makes sense.
So I guess in the end, I would say you are wrong. There is overriding being done. But I wouldn't say it's immediately obvious why that is the case. Interesting question!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With