Local classes & sealed classes

[Remi Forax]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "daniel smith" <daniel.smith at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 1 Mai 2020 23:17:00
> Objet: Re: Local classes & sealed classes

> Erring on the side of quick answers because time is getting tight.
> 
>> 1) A local class can extend a sealed class that lacks a 'permits' clause.
>>
>> The implicit list of permitted subclasses will include all classes declared in
>> the same compilation unit.
>>
>> sealed class A {
>>      void m() {
>>          final class B extends A {}
>>      }
>> }
>>
>> Note that the local class can't be declared 'sealed' or 'non-sealed'—see
>> below—but can be declared 'final'.
>>
>> There's nothing particularly wrong with this, other than the fact that it's
>> impossible to rewrite it with an explicit 'permits' clause.
>>
>> I can see it being a useful way to handle, say, an interface that declares a
>> handful of factory methods to produce a limited set of implementations.
> 
> We already prohibit lambdas and anonymous classes from extending sealed
> classes at all, inferred or not.  We didn't explicitly consider local
> classes (oops), but I wouldn't like this behavior. If you can't write
> down the permits clause, you shouldn't infer it. I think we should
> exclude local classes from candidacy.

I agree, if the name of the class is not constant (stable), the compiler should try to added it in a permits clause.

Rémi