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

[Mandy Chung]

On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> 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)

src/java.base/share/classes/java/lang/Class.java line 4381:

> 4379:      */
> 4380:     @jdk.internal.PreviewFeature(feature=jdk.internal.PreviewFeature.Feature.SEALED_CLASSES, essentialAPI=false)
> 4381:     public Class<?>[] getPermittedSubclasses() {

What happens if a permitted subclass is not found?   I see that `getPermittedSubclasses0` ignores the entry if the class is not found.    Should that be specified?

Have you considered whether security package access is needed (now that this method returns `Class` objects the caller may not have access to)? This needs to be discussed with the security team.    If someone gets a hold of a sealed class (e.g. `obj.getClass()`), this method could leak other `Class` objects.

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

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