(moving thread to amber-spec-experts, as this is a design question)
There’s two coupled features here, language and VM.
It is unquestionably the case that a PermittedSubtypes attribute should be
allowed to not only name classes that are not subtypes, but in fact do not
exist, are not accessible to the supertype, etc. Otherwise, it would simply be
too brittle. The hint is in the name — *permitted* subtypes. These classes
are permitted, not required, to be my subtype.
As to the language, basically all the choices (check, don’t check, warn) are
viable, and its a tradeoff of catching possible bugs vs being excessively
demanding on the user. Before we even address the question of “must J be a
subtype”, we first have to ask: how much work should the compiler do to find J
in the first place? Should it be permissible to say “permits
ClassThatDoesNotCurrentlyExist”? Or “permits
ClassThatExistsButIsInaccessibleToMe”?
There’s arguments for and against. If we want to type check the hierarchy in
this manner, it means that all the permitted subtypes be co-compiled (even if
they are in other compilation units, or even other packages) or their class
files be present when compiling. The “farther away” the other class is, the
more intrusive this restriction is. Where we settled is that classes in the
permits clause must be in the same module, and if it is the unnamed module must
be the same package, in part because that is our best approximation for groups
of classes that are co-compiled. But even this can be burdensome.
A related issue is that this is a new kind of restriction — where class A
imposes a restriction on some other class B in another compilation unit. We
should probably have a better reason than “I don’t see the point of allowing
this” before proceeding.
My preference would be for this to be a warning, not an error.
> On Sep 3, 2019, at 9:31 AM, fo...@univ-mlv.fr wrote:
>
> ----- Mail original -----
>> De: "Maurizio Cimadamore" <maurizio.cimadam...@oracle.com>
>> À: "Remi Forax" <fo...@univ-mlv.fr>, "amber-dev" <amber-...@openjdk.java.net>
>> Envoyé: Mardi 3 Septembre 2019 15:19:33
>> Objet: Re: permit with a class which is not a subtype is allowed
>
>> I think there might be a range of options here - error is one, lint
>> warning (e.g. redundant permits) is another.
>
> I don't see the point of being able to specify a type which is not a subtype
> given that it will never checked by the VM
> the VM only check when you load a class that if the parent as a an attribute
> PermittedSubtypes then the class is among the permitted subtypes.
>
> In my opinion, the attribute "PermittedSubtypes" should only store direct
> subtypes and it should be enforced by the compiler.
>
> otherwise you can write some fun stuff like
> sealed interface I permits J { }
> sealed interface J permits I { }
>
> note that I and J are not related in term of hierarchy.
>
>>
>> But, nevertheless you raise a valid point.
>>
>> Maurizio
>
> Rémi
>
>>
>> On 03/09/2019 14:03, Remi Forax wrote:
>>> The compiler allows to permit a class which is not a subtype.
>>>
>>> public class AncestorPermitExample {
>>> sealed interface I permits A {
>>>
>>> }
>>> final static class A {
>>>
>>> }
>>> }
>>>
>>> The VM too but it's not a bug for the VM (i believe).
>>>
>>> Rémi
