RFR: 8224243: Make AccessibleObject a sealed class

[Éamonn McManus]

Hi Joe,

I see that I blogged
<https://www.artima.com/weblogs/viewpost.jsp?thread=164042> about
AccessibleObject in 2006 and already complained about its protected
constructor back then. :-)

Still, if the main motivation of sealing it is to avoid adding @implSpec to
a few methods, perhaps it would be better just to bite the bullet and do
that? We can fix Guava's Invokable class so it no longer inherits from
AccessibleObject, and I think we probably should, but it would still be the
case that an app using a version of Guava from before the fix would fail
when deployed to a JDK with this change.

Thanks,
Éamonn

On Thu, 20 May 2021 at 15:47, Joe Darcy <joe.darcy at oracle.com> wrote:

> 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
>
>