Semantics of an empty PermittedSubtypes attribute for the VM

[Brian Goetz]

I'm mostly thinking of interfaces that will only be implemented by 
hidden classes.

On 4/3/2020 4:17 PM, John Rose wrote:
> On Apr 3, 2020, at 6:39 AM, Brian Goetz <brian.goetz at oracle.com 
> <mailto: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/2323b212/attachment.htm>