RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes
Athijegannathan Sundararajan
sundar at openjdk.java.net
Mon Mar 21 06:11:27 UTC 2022
On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy <darcy at 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
More information about the core-libs-dev
mailing list