The (potential) Return Of The Constant Interface Pattern

[Brian Goetz]

Yes and no :)

 From the perspective of the language and JVM specs, yes, it is indeed a 
trivial change to say that these bits (either at the ACC_* level or at 
the language modifier level) can be combined.

The question is whether the resulting language is perceived as better or 
worse for this.  I would expect the first -- and persistent -- reaction 
of nearly all users, when they encounter "abstract final class C { ... 
}" is: WTF?  It is hard to imagine at first what the purpose of an 
"abstract final" class would be; even when they learn that "abstract 
final" is a fancy name for "nonegleton" (like a singleton, but with one 
fewer instance), it will likely forever feel like a hack, because the 
intuitive meaning of these modifiers to most users doesn't lend 
themselves to easy combination.  The result is that the language becomes 
harder to learn and use; this is the hidden cost.

You are basically arguing: "I want nonegletons (though I might be happy 
with singletons in their place), and it seems cheap to get there by 
combining abstract and final, so let's do that."  Which is a reasonable 
argument as far as it goes, but I suspect that this is going to be one 
of those cases where you bought something mostly because it was cheap, 
and are now stuck with something that is cheaper than you want.

(If the language had a `non-instantiable` modifier (which IMO does not 
carry it's conceptual weight), a reasonable translation strategy would 
indeed be ACC_ABSTRACT + ACC_FINAL.)





On 12/19/2019 4:58 PM, Lucius User wrote:
> Hi.
>
> It is quite possible that i am missing something, but isn't it possible to "just" allow a class to both have ACC_FINAL and ACC_ABSTRACT, with the same effect as having a private constructor?
>
> Regards,
> Lucius.
>
>> On 19 Dec 2019, at 20:32, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>> Currently abstract classes and interfaces with no permitted subtypes are forbidden.
>>
>> The reason the “constant interface anti pattern” got off the ground at all is that it seemed like a clever abuse of the (flawed) inheritance of fields from interfaces.
>>
>> What I think you’re saying is: we need a place to put static fields (and maybe methods), and, while we have final classes, they’re annoying because you need to declare an inaccessible constructor to prevent them from being instantiated, and a sealed { abstract class, interface } with no permitted subtypes would be a shorter path to get to “non instantiable classes”?   (Indeed, this is an argument that could have been made 25 years ago: “can we have final interfaces?”.)
>>
>> I don’t think that getting there via sealed interfaces is really any more attractive than getting there via final classes with an inaccessible constructor; both seem to be stretching the intent equally….
>>
>>> On Dec 19, 2019, at 12:10 PM, Christian Stein <sormuras at gmail.com> wrote:
>>>
>>> Hi.
>>>
>>> After reading https://https://openjdk.java.net/jeps/360 I wonder
>>> if an empty set of permits is allowed for an sealed interface.
>>>
>>> Something like this:
>>>
>>>   sealed interface Constant permits EMPTY_SET {
>>>     Number N = 123;
>>>   }
>>>
>>> Looking at resurrecting the "constant interface pattern" --
>>> without the disadvantage of somebody being able to
>>> implement that interface even in the same maintenance
>>> domain as the type itself.
>>>
>>> Cheers,
>>> Christian