Compiler implementation for Sealed Classes (Second Preview)

Summary

Since the release of the "Sealed Classes" feature JEP 360 in Java SE 15, a small number of clarifications, enhancements and fixes have been identified. The feature will preview for a second time in JDK 16.

Problem

Following testing, as well as feedback and discussions, the following issues with the "Sealed Classes" preview feature have been identified:

• The JLS is not clear about the use of context when applying the lexical grammar, particularly in the identification of what is described as contextual keywords. This affects, in particular, the new keywords introduced by this JEP: sealed, non-sealed, and permits.

• A local class is not be permitted to extend a sealed class or implement a sealed interface. Accordingly a local class should not be considered when determining the implicitly permitted subclasses of a sealed class or interface.

• The current specification for narrowing reference conversions is too permissive, in that knowledge of sealed hierarchies could be used to identify erroneous casts and instanceof expressions at compile-time.

• It has been suggested that the return type of method java.lang.Class::permittedSubclasses should not be java.lang.constant.ClassDesc[], both for consistency issues and because it would force users to use the java.lang.constant API which is mostly intended for advanced users. It has also been suggested that the name of the method should be getPermittedSubclasses also on consistency basis.

Solution

• Clarify the use of context when applying the lexical grammar, in particular by introducing a first class notion of contextual keywords (formerly described as "restricted identifiers" and "restricted keywords"). Then the character sequences sealed, non-sealed, and permits can be defined as contextual keywords.

• Do not consider local classes when calculating the implicitly declared permitted direct subclasses of a sealed class or interface.

• Extend the notion of a narrowing reference conversion to explicitly navigate sealed hierarchies to determine if a conversion can be rejected at compile-time.

• Change the return type of method java.lang.Class::permittedSubclasses to java.lang.Class<?>[] and rename it as getPermittedSubclasses

Specification

• A new companion specification document that clarifies the treatment of contextual keywords is attached.

• Section 8.1.6 Permitted Direct Subclasses, has been modified to state that if a sealed class C lacks a permits clause, local classes are not considered as permitted direct subclasses of C.

• Section 5.1.6.1 Allowed Narrowing Reference Conversion has been modified in order to clarify the cases for which a narrowing reference conversion exist if sealed classes or interfaces are involved in the conversion.

• The specification for method java.lang.Class::permittedSubclasses has been updated as follows:

    -     * Returns an array containing {@code ClassDesc} objects representing all the
    +     * Returns an array containing {@code Class} objects representing all the
          * direct subclasses or direct implementation classes permitted to extend or
          * implement this class or interface if it is sealed. The order of such elements
          * is unspecified. If this {@code Class} object represents a primitive type,
          * {@code void}, an array type, or a class or interface that is not sealed,
          * an empty array is returned.
          *
    -     * @return an array of class descriptors of all the permitted subclasses of this class or interface
    +     * @return an array of class objects of all the permitted subclasses of this class or interface
          *
          * @jls 8.1 Class Declarations
          * @jls 9.1 Interface Declarations
          * @since 15
          */
         @jdk.internal.PreviewFeature(feature=jdk.internal.PreviewFeature.Feature.SEALED_CLASSES, essentialAPI=false)
         public Class<?>[] getPermittedSubclasses() {}