| Claim | Verdict |
|---|
| Return type must match exactly | False. Covariant returns are allowed. |
| Access may be narrowed | False. Widening only. |
| Checked exceptions may be added | False. Narrowing only. |
| Static methods are overridden | False. They are hidden. |
| Private methods are overridden | False. They are invisible. |
@Override changes behaviour | False. It is compile-time only. |
| A renamed parameter type still overrides | False. It becomes an overload. |
| Overriding needs a cast | False. The JVM dispatches for you. |
Frequently Asked Questions
What makes a method an override rather than an overload?
Whether the parameter list is unchanged. An override keeps the same name, parameter types, and arity, while an overload changes the parameters and leaves the inherited method in place. Changing a parameter type or reordering parameters produces an overload, even when it looks like a correction of a typo.
Can an overriding method return a different type?
Yes, as long as the type is a subtype of the declared return type, which is called a covariant return. The reverse is rejected, because callers compiled against the parent return type could not handle a wider result. Covariance tightens the contract without changing what existing code sees.
Can an override reduce visibility?
No. An override may widen access but never narrow it, so a public parent method cannot become protected in the child. This preserves substitutability, since code holding a supertype reference must still be able to call the method it was promised.
What exceptions may an override throw?
Only a subset of what the parent declared, and never a new checked exception, since callers of the parent type have not agreed to handle it. Unchecked exceptions are exempt because callers were never required to catch them. Narrowing in this way is safe because the parent contract is always honoured.
Which methods can never be overridden?
Static methods, because they belong to the class rather than the object, so a same-named method hides rather than overrides them. Private methods, because a subclass cannot see them. Final methods, because the parent forbids it. A package-private method also cannot be overridden from a different package, since it is invisible there.
What does the @Override annotation actually do?
Nothing at runtime. It instructs the compiler to verify that the method really overrides an inherited one, so a mismatched signature becomes a build failure rather than a new method that silently does nothing useful. It is not mandatory, but it is the cheapest guard against a signature drifting out of sync with the parent.
Do I need a downcast to reach an override?
No. When a method is called through a supertype reference, the JVM already selects the override belonging to the actual object. A cast is needed only to access a method that exists on the child but not on the parent, which is a separate concern from dispatch.
Why must equals and hashCode be overridden together?
Because the contract requires that equal objects produce equal hash codes. Overriding equals alone leaves two equal objects in different hash buckets, so a HashSet can contain both and a HashMap lookup can miss an entry that is present. Overriding both keeps the two consistent.