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
