The (potential) Return Of The Constant Interface Pattern

[Lucius User]

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
>