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

[Alan Bateman]

On Tue, 1 Dec 2020 23:19:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I was investigating a little today. One thing to note is that there is a difference between the JLS and JVMS[1] restrictions - the JVMS restrictions only require the classes to be in the same module, but they can be in any package (even for an unnamed module).
>> 
>> Moreover, a lot of the constraints are checked automatically: e.g. consider class api.Api in module "a", which permits impl.Impl in module "b", subtyping Api. Loading of impl.Impl on behalf of getPermittedSubclasses() will fail (because the two classes are in different modules). So impl.Impl will not be included.
>> 
>> So far, it seems the only constraint that I think is not satisfied by this implicit loading is that the permitted subclass is really a direct subtype of the current class.
>> 
>> My proposal is to enhance the Java method with the direct subtype check (with a possible future cleanup task to move the check to native, as is done for getNestMembers()). 
>> 
>> [1] http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html#jvms-5.3.5
>
> @lahodaj  It is okay with me if `getPermittedSubclasses` returns the permitted subtypes matching the runtime view (that matches the current specification to me) and revisit this API as a follow up.

Yes, would be a surprise if getPermittedSubclasses returned Class objects for classes that are not subclasses. I think it should be okay to separate that out to a separate issue so that it can be further re-examined after JEP 397 goes in.

-------------

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