The (potential) Return Of The Constant Interface Pattern

Brian Goetz brian.goetz at oracle.com
Thu Dec 19 17:32:15 UTC 2019


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



More information about the amber-dev mailing list