On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy <da...@openjdk.org> wrote:
> Small refactoring to use sealed classes in the MethodHandle implementation > hierarchy. > > 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. > > Please also review the corresponding CSR > https://bugs.openjdk.java.net/browse/JDK-8283434 "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? ------------- PR: https://git.openjdk.java.net/jdk/pull/7881
