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

John Rose john.r.rose at oracle.com
Fri Apr 23 20:19:17 UTC 2021


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


More information about the amber-spec-experts mailing list