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

[Harold Seigel]

On Mon, 30 Nov 2020 19:44:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Improving getPermittedSubclasses javadoc.
>>  - Merge branch 'master' into JDK-8246778
>>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>>  - Improving getPermittedSubclasses() javadoc.
>>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>>  - Removing unnecessary file.
>>  - Tweaking javadoc.
>>  - Reflecting review comments w.r.t. narrowing conversion.
>>  - Improving checks in getPermittedSubclasses()
>>  - Merging master into JDK-8246778
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179
>
> 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.

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

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