> On May 1, 2020, at 3:38 PM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
> ----- Mail original -----
>> De: "Brian Goetz" <brian.go...@oracle.com>
>> À: "daniel smith" <daniel.sm...@oracle.com>, "amber-spec-experts"
>> <amber-spec-experts@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.
The fact that some classes have unstable binary names is not an issue.
Everything in the compilation unit gets recompiled at once, including the
sealed superclass and the extending subclass. (You might be concerned about,
say, Javadoc listing a local class among the permitted subclasses, which it
really shouldn't, but it's the same problem with private member classes. Some
sealed classes have publicly-exposed exhaustive lists of subclasses; others do
not.)
