RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

Chris Hegarty chegar at openjdk.java.net
Wed Dec 2 17:48:57 UTC 2020

On Wed, 2 Dec 2020 17:39:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> ...
> Uh, I just realized it may be necessary to implement `Class.isSealed()` differently. Consider:
> ```
> sealed class Sealed permits Unknown {}
> ```
> Where `Unknown` does not exist at runtime. So getPermittedSubclasses0() returns an empty array(?). But isSealed should return `true`, right? (Possibly, we could leave this from the first integration, but seems like something that should be done. Note that in the previous/JDK 15 implementation, isSealed() would return true in this case.)

@lahodaj  I raised this issue here: https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-October/002626.html

Relevant comment inline:
> The recent change (proposed on this list) to Class::getPermittedSubclasses, means that it will no longer be possible to reflectively return permitted subclasses that are not loaded, or more specifically “loadable" - the classes must exist somewhere. Currently, in JDK 15, permittedSubclasses will return class descriptors for non-loadable classes. I think that this is ok, we just need to ensure that it fits into the other rules here.

Yep. I think this is a good change, and I think there's nothing wrong with the reflection API either ignoring some entries or reporting class loading errors. Best to do whatever the NestMembers query does.


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

More information about the compiler-dev mailing list