Semantics of an empty PermittedSubtypes attribute for the VM

[John Rose]

On Apr 3, 2020, at 6:39 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 
> 
>> You might think I’m arguing here for allowing S to be
>> an empty set, and I might in similar cases, but there are two
>> other reasons to outlaw the edge case, rather than ask
>> the spec. to account for it (either by extending the general
>> rule, or adding a special rule).  First, if C wants to permit
>> exactly zero subclasses, there’s already a notation for that.
>> 
> 
> 
> … unless C is an interface. 

Yes, sure.  If there’s a use case for a never-implemented interface
(I can think of a few) then we could either (a) allow interfaces to
be marked final, or (b) allow empty permit lists, at the cost of
the earlier objections (hey, it’s kinda confusing + two ways to
say the same thing for non-interfaces).

The most straightforward way to get the effect of a never-implemented
interface is to give it a permits list which references no implemented types.

The most straightforward way to do *that* is make the permits list
empty.  But there are other ways to get that effect.  Make the permits
list be a singleton reference to a private class that is either non-existent
(never loaded because no classfile) or that is abstract and (somehow)
permits no subtypes.  In either case the JVM can be asked to observe
that no instances are possible.

Which tactic is best here?  I suppose that depends on the use cases.
If we are supposing users will want to use non-implemented
interfaces as some sort of design pattern, then “final” interfaces, or
empty permits lists, are in the cards.   But if it’s some kind of one-off
thing (like an interface version of jl.Void) then the notation can be
ugly, since it can be done once with adequate explanatory comments.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200403/187e1408/attachment.htm>