[sealed-types] Draft Spec for JEP 409 Sealed Types (Final)

[Gavin Bierman]

Sorry, meant to thank you for pointing this out. You are correct in that (i) when writing these I wrote them side-by-side, and (ii) when we fixed up the text surrounding top-level/member/local I forgot to put them side-by-side again to check there wasn’t any stray old text. Ug.

(It’s also super annoying that the section numbers don’t match to make this even better!)

Alex spotting a small issue that will break up this nice symmetry some more: the restriction on the canonical name excludes the neat trick that we play compiling out enums with constants that have bodies into a sealed hierarchy (as we need to have permitted subclasses that are anonymous classes). It’s fixable but we have to special case enum classes :-(

Thanks again,
Gavin

> On 23 Apr 2021, at 21:19, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Apr 20, 2021, at 2:00 AM, Gavin Bierman <gavin.bierman at oracle.com> wrote:
>> 
>> 
>> http://cr.openjdk.java.net/~gbierman/jep409/latest/
> 
> Out of curiosity I compared the two large new sections
> on permits, 8.1.4 and 9.1.4, perhaps to find unintentional
> divergences.  Here are the differences I found FYI,
> aside from than the required differences arising
> from section numbering and the parallel terminology
> of interfaces and lists.
> 
>> The optional permits clause in a [C/I] declaration {specifies, lists} the [C/I]s
> 
>> It is a compile-time error if {the same class, a class or interface} is {specified, named} more than once in a {, single} permits clause
> 
>> The permitted direct sub[C/I]s of a sealed [C/I] are the [C/I]s listed by its permits clause, or, if [C/I] lacks a permits clause, each {, top level or member} [C/I] declared in the same compilation unit as [C/I] (7.3) which has a canonical name (6.7)
> 
> This last one is especially odd, since “top level or member”
> seems redundant when “has a canonical name” is specified.
> The latter condition is in both places, and is more pertinent.
> 
> Also, this comment was in the class section, but there was no
> parallel comment in the interface section:
> 
>> This means that if a sealed class C lacks a permits clause one will be inferred that contains all the top-level and member classes in the same compilation unit that list C as their direct superclass. The requirement of having a canonical name means that no local classes or anonymous classes will be considered.
> 
> Perhaps you added the “canonical name” and did not replace
> all of the predecessor language about “top level or member”?
> 
> (As expected, I found no substantive differences.)
> 
> — John