[sealed-classes] Spec for next version of Sealed Classes

[Chris Hegarty]

Gavin,

Comments relating to the JVMS:

(Many of my comments relate to the wellformedness of the PermittedSubclasses Attribute, which may or may not be strictly specified, so take with a pinch of salt! ;-) )

I find myself mapping the set of allowable values in the PermittedSubclasses Attribute to the behaviour of the Core Reflection API, to discern; what is enforced by the VM and what is possible to be observed reflective at run-time.

The `number_of_classes` is not required to be a non-zero, but I expect that it should. Or maybe this is implicit or specified/enforced elsewhere?

"Array items that do not attempt to directly extend or implement the current class or interface are ignored.” - Ok, so such items can be from any runtime module or package, right?   Related to `number_of_classes`, the requirement is really that there is at least one non-ignored item, no? ( if enforced at all )

The recent change (proposed on this list) to Class::getPermittedSubclasses, means that it will no longer be possible to reflectively return permitted subclasses that are not loaded, or more specifically “loadable" - the classes must exist somewhere. Currently, in JDK 15, permittedSubclasses will return class descriptors for non-loadable classes. I think that this is ok, we just need to ensure that it fits into the other rules here.

"C does not have its ACC_PUBLIC flag set (4.1) and the superclass belongs to a different run-time package than C.” - I get that there is a bidirectional accessibility relationship between the superclass and the subclass, but this seems at odds with JEP text:  “In particular, a subclass may be less accessible than the sealed class”. Why is this not that the superclass must have ACC_PUBLIC, and not the subclass?

Duplicate entries in the `classes` array are effectively ignored? They must be elided by Class::getPermittedSubclasses, right? Or can duplicates be propagated through this API point?

Comments relating to the JVLS:

Trivial type in 5.1 - "This is *is* the underlying notion used in the definition of narrowing reference conversion. "

"Changing a class that is declared non-sealed to no longer be declared non-sealed does not break compatibility with pre-existing binaries.” - doesn’t this depend on the whether or not the superclass/superinterface is sealed? And whether it has subclasses or not ?

-Chris.


> On 23 Oct 2020, at 16:16, Gavin Bierman <gavin.bierman at oracle.com> wrote:
> 
> Dear all:
> 
> Drafts of the specs for the Sealed Classes feature that we plan to preview for
> a second time in JDK 16 are now available:
> 
> http://cr.openjdk.java.net/~gbierman/8246775/latest/
> 
> [NB: The URL will change once we have a JEP number, and will be announced.]
> 
> The changes are the same as those in the first preview that was released in Java
> SE 15, except for minor editorial changes and the following:
> 
> - Clarification the use of context when applying the lexical grammar,
>  particularly in the identification of contextual keywords (formerly described
>  as "restricted identifiers" and "restricted keywords"). This is detailed in a
>  companion document entitled “Contextual Keywords". The keywords `sealed`,
>  `non-sealed`, and `permits` are now defined as new instances of contextual
>  keywords (3.9). 
> 
> - This spec now assumes that the changes detailed in companion documents
>  entitled "Consistent Class and Interface Terminology” and "Local and Nested
>  Static Declarations" have been applied (these are being introduced as part of
>  the Records JEP). In particular, this means that Java SE 16 will support
>  static declarations in two new positions:
> 
>    1. Local, implicitly-static interfaces and enum classes
>    2. Static members of inner classes
> 
>  This requires asserting that local interfaces are not permitted to be
>  `sealed`. (14.3)
> 
> - To enhance narrowing reference conversion to allow for stricter checking of
>  cast conversions with respect to sealed type hierarchies (5.1.6.1). 
> 
> - Local classes are not considered when determining implicitly declared
>  permitted direct subclasses of a `sealed` class or `sealed` interface
>  (8.1.6, 9.1.4).
> 
> 
> Comments welcome!
> 
> Gavin