> On Nov 24, 2020, at 5:44 AM, Chris Hegarty <chris.hega...@oracle.com> wrote:
>
> Dan,
>
>> On 29 Oct 2020, at 21:29, Dan Smith <daniel.sm...@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.
