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

[Mandy Chung]

On Mon, 30 Nov 2020 20:57:32 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 4480:
>> 
>>> 4478:     }
>>> 4479: 
>>> 4480:     private native Class<?>[] getPermittedSubclasses0();
>> 
>> Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS:
>> 
>>    - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C
>>    - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C
>> 
>> I didn't check the VM implementation.
>> 
>> If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified.
>
> The JVM method that returns the permitted subclasses (and interfaces) does not weed out permitted subclasses based on the above module requirements.  It returns all the classes listed in the PermittedSubclasses attribute that it is able to load.

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.

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

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