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.da...@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 > >
