----- Mail original -----
> De: "daniel smith" <daniel.sm...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Envoyé: Mardi 5 Mai 2020 23:50:01
> Objet: Re: Local classes & sealed classes
>> 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.)
it is because:
- you may not recompile all the codes that depends on the permitted subclasses
list, what about a switch somewhere, what about a generated code based on an
annotation processor or using the reflection API.
- as you said, it's visible using javadoc, allowing an unstable binary name to
be part of the public API is not a good idea, we already have this issue with
inner classes and the serialization, let's not add another footgun.
regards,
Rémi
