Semantics of an empty PermittedSubtypes attribute for the VM
Brian Goetz
brian.goetz at oracle.com
Fri Apr 3 20:36:32 UTC 2020
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>
More information about the amber-spec-experts
mailing list