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 Hmm.. I tried the following example: $ cat com/acme/X.java package com.acme; // We can omit permits clause if all the subclasses are in the same compilation unit. // But that's applicable here as two subclasses "Z", "P.Q" are outside the compilation unit. // So we use explicit permits clause that lists all the subclasses. public sealed class X permits X.Y, W, Z, P.Q { final class Y extends X {} } final class W extends X {} $ cat com/acme/Z.java package com.acme; final class Z extends X { } $ cat com/acme/P.java package com.acme; class P { final class Q extends X {} } $ javac com/acme/*.java is fine. Am I missing something? ------------- PR: https://git.openjdk.java.net/jdk/pull/7881
