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? On Thu, 20 May 2021 at 10:36, Alan Bateman <al...@openjdk.java.net> wrote: > On Thu, 20 May 2021 17:14:57 GMT, Joe Darcy <da...@openjdk.org> wrote: > > > Conceptually, AccessbileObject is a sealed class with a protected > constructor stating > > > > Constructor: only used by the Java Virtual Machine. > > > > With the language now supporting sealed classes, the AccessbileObject > should be marked as sealed. > > > > Executable and Field are the subclasses of AccessbileObject in the JDK; > as Executable has subclasses, it is marked as non-sealed. > > > > Please also review the corresponding CSR: > > > > https://bugs.openjdk.java.net/browse/JDK-8224243 > > I think this will require reaching out to Google Guava, I think its their > Invocable API that extends AccessibleObject outside of the JDK. We ran this > when doing the module system where we didn't initially take into account > sub-classes that were outside of java.base. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4133 >
