RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes

[Joe Darcy]

On Mon, 21 Mar 2022 04:04:45 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> "DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses."
> 
> We can have a permits clause that lists fully qualified class name for the nested class and simple name for that separate type in the same package, right?
> 
> Also
> 
> $ cd $jdk_src/src/java.base/share/classes/java/lang/invoke $ grep "extends DelegatingMethodHandle" * MethodHandleImpl.java: private static final class AsVarargsCollector extends DelegatingMethodHandle { MethodHandleImpl.java: static class CountingWrapper extends DelegatingMethodHandle { MethodHandleImpl.java: private static final class WrappedMember extends DelegatingMethodHandle { MethodHandleImpl.java: static final class IntrinsicMethodHandle extends DelegatingMethodHandle
> 
> All 4 are nested classes. Two of those subclasses are nested "private" in another class and hence cannot be referred from DelegatingMethodHandle's permits clause, right?

I did try to name the nested type in the permits clause, and it was not accepted by javac. (If all the subclasses are in the same compilation unit, either as auxiliary classes or nested classes, an explicit permits clause can be skipped as the compiler will infer it.)

Per your other point about the nested classes in MethodHandleImpl, JLS 8.1.6 states:

"Every TypeName [in the permits clause] must name an accessible class ([§6.6]), or a compile-time error occurs."

so the private classes of another class would not be accessible either.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7881