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? -Chris.
