RFR: 8224243: Make AccessibleObject a sealed class

Joe Darcy joe.darcy at oracle.com
Thu May 20 22:47:39 UTC 2021


Hi Éamonn,

On 5/20/2021 2:59 PM, Éamonn McManus wrote:
> Thanks for the tip, Alan. Guava's public Invokable
> <https://javadoc.io/doc/com.google.guava/guava/latest/com/google/common/reflect/Invokable.html>
> class does inherit from AccessibleObject. It would probably not be too hard
> to make it stop doing so. That's technically a breaking API change, but the
> class is marked @Beta so that's fair game.
>
> I looked in Google's code base and I found one other project that extends
> AccessibleObject, picocli, here
> <https://picocli.info/apidocs/picocli/CommandLine.Model.MethodParam.html>.
> That's not to say that nobody else does it, but apparently cases are rare.
>
> I do wonder what the purpose of the change would be. The constructor
> javadoc text doesn't say you *can't* extend this class. Is there some
> benefit from making it not work anymore?
>

The intent of the constructor's text to me implies the class is not 
intended to be subclassed outside of the JDK. (I'm not sure why the 
constructor isn't package private as all its subclasses are in the same 
package which would have accomplished that, but the SCM history from 
circa JDK 1.2 would need to be consulted for guidance.)

The original impetus for 8224243 was the implementation of certain 
overridable methods in AccessibleObject (getAnnotation, 
getAnnotationsByType, and getDeclaredAnnotations) not @implSpec'ing 
their behavior. The behavior is to thrown an error as the method should 
be overridden in the subclasses. If all the subclasses are within the 
JDK and the class is sealed, that @implSpec'ing need not occur.

If all the subclasses were in the JDK (which we know is not that case), 
it is preferable to avoid the @implSpec'ing throwing the exception as 
that is just an implementation-internal comment.

HTH,

-Joe



More information about the core-libs-dev mailing list