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 <[email protected]> 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
