According to JLS,
The access modifier of an overriding or hiding method must provide at least as much access as the overridden or hidden method, or a compile-time error occurs. The allowed accesses are:
Overridden/hidden method modifier |
Overriding/hiding method modifier |
|---|---|
public |
public |
protected |
protected or public |
default |
default or protected or private |
private |
anything but private |
This also means that there is potential for some functionality having a restrictive modifier to be overridden by a less restrictive modifier.
Non-Compliant Code Example
This non-compliant code example exemplifies how a malicious subclass Sub can override the doLogic method of the super class. Any user of Sub will be able to invoke the doLogic method even though the base class BadScope defined it with the private access modifier.
class BadScope {
private void doLogic() {System.out.println("Super invoked");}
}
public class Sub extends BadScope {
public void doLogic() {System.out.println("Sub invoked");
//do restrictive operations
}
}
Compliant Solution
Do not override a method unless absolutely necessary. Declare all methods and fields final to avoid malicious subclassing. This is in compliance with <xyz rule>
class BadScope {
private final void doLogic() {System.out.println("Super invoked");}
}
References
JLS 8.4.8.3 Requirements in Overriding and Hiding