[sealed-classes] Spec for next version of Sealed Classes
Chris Hegarty
chris.hegarty at oracle.com
Tue Oct 27 16:56:45 UTC 2020
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
More information about the amber-spec-experts
mailing list