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

[Dan Smith]

> On Nov 24, 2020, at 5:44 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Dan,
> 
>> On 29 Oct 2020, at 21:29, Dan Smith <daniel.smith at oracle.com> wrote:
>> 
>>> ...
>> 
>>> "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?
>> 
>> The goal of this rule is to simulate resolution without actually asking to perform it, since the class hasn't even been created yet. Part of resolution is access checking, so we simulate it here.
>> 
>> The JEP says "a permitted subclass and its sealed superclass must be accessible to each other. However, permitted subclasses need not have the same accessibility as each other, or as the sealed class."
>> 
>> Keep in mind we're talking now about language-level accessibility, which doesn't always map to JVM accessibility.
> 
> Understood. My question is only related to accessibility in the JVM.
> 
>> Anyway, some examples:
>> public super, non-public sub, same package
>> package-access super, private sub, same package
>> public *and exported* super, public sub
>> private super, public sub, same nest
> 
> Thanks for these examples, they are helpful.
> 
> Here is one more:
>  public super, non-public sub, same module, DIFF package
> 
> The draft text [*] seems to explicitly disallow this (which I believe is incorrect, or at least I don’t understand why).
> 
> [*] “ ... derivation fails with a IncompatibleClassChangeError: ...
>   * C does not have its ACC_PUBLIC flag set (4.1) and the superclass belongs to a different run-time package than C.  …"
> 
> I believe that the intent is that “SUPERCLASS does not have its ACC_PUBLIC flag set (4.1) and C belongs to a different run-time package than SUPERCLASS” - not the other way around. No?

We're simulating resolution of a reference to C appearing in the superclass. (See "accessible to each other" in the JEP text I quoted.)

If you were to actually resolve the reference to C (where C is non-public and in a different package), you would get an IAE, because the superclass can't "see" C. Thus, extending the superclass with C is disallowed.