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

[Mandy Chung]

On Tue, 1 Dec 2020 16:49:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> So it could also return a class listed in `PermittedSubclasses` attribute but not a subclass of this sealed class, right?
>> 
>> The specification of `Class::getPermittedSubclasses` says:
>> 
>>> Returns an array containing {@code Class} objects representing the direct subclasses or direct implementation classes permitted to extend or direct subinterfaces or subclasses permitted to extend or implement this class or interface if it is sealed. 
>> 
>> I expect that `Class::getPermittedSubclasses` should do more work and return only the subclasses or subinterfaces permitted at runtime.
>
> 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.

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

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