RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)
mchung at openjdk.java.net
Wed Dec 2 17:59:56 UTC 2020
On Wed, 2 Dec 2020 17:39:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:
> Additional changes may be needed to Class.permittedSubclasses() and/or Class.isSealed() as part of fixing bug JDK-8256867. The JVM is being changed to treat classes with empty PermittedSubclasses attributes as sealed classes that cannot be extended (or implemented).
> Current thinking is that Class.permittedSubclasses() will return an empty array for both non-sealed classes and for sealed classes with empty PermittedSubclasses attributes. And, Class.isSealed() will return False in the former case and True in the latter. This will require changing the implementation of Class.isSealed() to call the JVM directly instead of calling Class.permittedSubclasses().
> Does this seem like a reasonable way to handle this corner case?
I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype.
If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null.
More information about the compiler-dev