Page History

According to the Java Language Specification \[[JLS 2005|AA. Java References#JLS 05]\], section 8.4.8.3 "Requirements in Overriding and Hiding":

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 following are the allowed accesses are:

...

Do not override a method unless absolutely necessary. Declare all methods and fields final to avoid malicious subclassing. When this is not possible, refrain from increasing the accessibility of overridden methods. This is in compliance with the tenets of guideline SEC01-J. Minimize the accessibility of classes and their members.

...

According to Sun's Secure Coding Guidelines [[SCG 2007]]:

In addition, refrain from increasing the accessibility of an inherited method, as doing so may break assumptions made by the superclass. A class that overrides the protected java.lang.Object.finalize method and declares that method public, for example, enables hostile callers to finalize an instance of that class, and to call methods on that instance after it has been finalized. A superclass implementation unprepared to handle such a call sequence could throw runtime exceptions that leak private information, or that leave the object in an invalid state that compromises security.

...

It is recommended but not mandatory to limit the accessibility of a subclass's constructor to that of the superclass's constructor.

Exceptions

SPC01-EX1: According to Sun's Secure Coding Guidelines [[SCG 2007]]:

One noteworthy exception to this guideline pertains to classes that implement the java.lang.Cloneable interface. In these cases, the accessibility of the Object.clone method should be increased from protected to public.

...

Subclassing allows access restrictions to be weakened, possibly compromising the security of a Java application.

...