permit with a class which is not a subtype is allowed
brian.goetz at oracle.com
Tue Sep 3 18:56:11 UTC 2019
I get it, you prefer this way, as you've now said several times. And as
I've now said several times, this is ONE of the reasonable
possibilities, and is already under consideration. It might even be the
best one. But it is definitely, positively, not the ONLY reasonable one.
I'm not ready to decide this today, but you've more than made your case
for your preferred outcome, so I think its time to let it sit, OK?
On 9/3/2019 2:42 PM, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "Brian Goetz" <brian.goetz at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>> Envoyé: Mardi 3 Septembre 2019 18:13:58
>> Objet: Re: permit with a class which is not a subtype is allowed
>>> And you have the second effect which is, if the permit clause raise a warning
>>> when the class doesn't exist, it logically also means that the case clause of a
>>> switch on type also raises a warning when the class doesn't exist.
>> This is true, but remember such things can happen in different files.
>> The real question is whether the naming of a type in a permits clause is
>> a _use_ of that type. (Clearly, naming a type in a case clause is a
>> use.) So while it would be impossible for a switch to proceed without
>> being able to find all the types it names, the same is not necessarily
>> true for the declaration.
> Until Java 9, every mention of a name not at a declaration site was a use, it was relaxed in Java 9 in module-info in case of a cross module reference because you may not want to compile several modules at the same time (and as far as i know Maven still is not able to do that). We have decided that a closed hierarchy should refer to types inside the same module, so it should be a use.
> For the switch on type, the current equivalent of a switch on type is a visitor, so people will expect that they will be able to retrofit a visitor to a switch on type. In a visitor, the expression of each case is isolated in its own method so if the type taken as parameter is not present, it's not a problem, the method can not be called (technically it even better because it can be called with null and it will still work). So at runtime, i think its reasonable to not raise an IncompatibleClassChange if one of the type of the case doesn't exist. So we are exactly in a similar case as with the permit clause, it should not be a problem at runtime but you want the compiler to consider them as use at compile time.
More information about the amber-spec-observers