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

Mandy Chung mchung at openjdk.java.net
Mon Nov 30 19:48:00 UTC 2020

On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> From the original PR:
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>>     * adding code to make sure that annotations can't be sealed
>>>     * improving some tests
>>> TIA
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
> 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

Should the library implementation of `Class::getPermittedSubclasses` filter that if not done by `getPermittedSubclasses0`?

If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified.


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

More information about the compiler-dev mailing list