Selaed classes cant permit private classes

[Maurizio Cimadamore]

Hi,
I’m not sure whether the error you get is legit or not, but I observe 
that it’s not just about sealed classes - e.g. something like

|class Tmp<X extends Tmp.A>|

results in the same behavior.

I think this is due to JLS 6.3:

> The scope of a declaration of a member |m| declared in or inherited by 
> a class or interface C (§8.2 
> <https://docs.oracle.com/javase/specs/jls/se22/html/jls-8.html#jls-8.2>, 
> §9.2 
> <https://docs.oracle.com/javase/specs/jls/se22/html/jls-9.html#jls-9.2>) 
> is the entire body of C, including any nested class or interface 
> declarations. If C is a record class, then the scope of |m| 
> additionally includes the header of the record declaration of C.
>
That is, an “extends” or “permits” clause is not really type-checked as 
if inside the body of class C. This results in the accessibility problem 
you point out (which might or might not be a compiler glitch, I don’t 
think the JLS is crystal clear on how Tmp.A should be checked).

That said… back to your immediate problem - whenever you have nested 
classes extending from a toplevel class, you can just omit “permits” and 
leave it to javac, like so:

|sealed class Tmp { private static final class A extends Tmp { ... } // 
ok } |

This should allow what you want to do.

Maurizio

On 26/08/2024 13:28, Olexandr Rotan wrote:

> Hello. Recently, I have started a new project to explore Babylon code 
> reflection API (LInq), and thought that using sealed classes to 
> represent operand type would be really suitable (function calls, 
> column refs etc.). However, I want to only expose one 
> interface/abstract class for each of those types, while actual 
> implementations are private classes inside sealed classes. However, 
> when I tried to compile something like this (simplified for brevity):
>
> sealed class Tmppermits Tmp.A {
>      
>      private static final class Aextends Tmp {
>      }
> }
> I got following error:
> error: A has private access in Tmp
> Is this behaviour expected or not? (I would assume second since 
> intellij code analysis didn't mark this as error) If it's later, I 
> would ask some JDK member to file a bug report (I noticed that they 
> are processed faster then non-member requests), and I will try to fix 
> this. If it`s premier, then what is the motivation behind this?

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240826/37e96231/attachment-0001.htm>