Local classes & sealed classes

forax at univ-mlv.fr forax at univ-mlv.fr
Tue May 5 22:23:25 UTC 2020

----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at 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 <forax at univ-mlv.fr> wrote:
>> ----- 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.
> 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.


More information about the amber-spec-experts mailing list