permit with a class which is not a subtype is allowed

[Brian Goetz]

(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, forax at univ-mlv.fr wrote:
> 
> ----- Mail original -----
>> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>, "amber-dev" <amber-dev at 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