Interface Related Improvements
Brian Goetz
brian.goetz at oracle.com
Sun Nov 8 13:25:25 UTC 2020
I can briefly cover the state of these. The summary is: none of these
are new ideas, some are "on the list", and some are not.
> *_Private fields_*
>
> Since interfaces currently can have private methods it would be much
> desirable to have private fields also. These can static or instance
> fields, but minimally at least private static fields initially.
In hindsight, it was an omission to cover private fields and nested
classes when private methods were added to interfaces in Java 9. This is
on the list to address, though not of the highest priority. (Arguably
private nested classes are more important than private fields.)
> *_Initializers_*
>
> Interfaces can add initialisers. These will only run one. Minimally at
> least static initialisers initially.
Initializers should run where the state is, and interfaces do not have
instance state, so instance initializers are not inappropriate (and
would be an endless source of puzzlers regarding the order in which they
run). They can have static fields; these static fields can have
initializer expressions, but static initializer blocks are not
permitted. Static initializers are not an unreasonable idea, but also
not a very high-leverage feature, and so are a low priority.
> *_Improvements to Annonymous Inner Classes to work with the new Java
> Interfaces_*
>
This has been requested before; essentially, an extension of the limited
support for intersection types to anonymous class creation instances.
Again, not an unreasonable idea, but there's a trivial refactoring you
can make to give you this: use named local classes. Instead of asking for:
X x = new X()&Y { ... }
you can use a local class:
void m() {
class Foo extends X implements Y { ... }
X x = new Foo();
}
Or, if the interface you want is a functional interface, you can use an
intersection type as a target type:
X x = (X & Y) <lambda>
>
> *_Improving Enums to work with the new Java Interfaces_*
>
JEP 301 (Enhanced Enums) explored solutions in this space, but after
spending a great deal of effort, it turned out that solving this problem
was going to be much more complicated than one might have initially
thought. There's some notes here:
http://cr.openjdk.java.net/~mcimadamore/amber/enhanced-enums.html
Summary: there are many small improvements we could make to enums, and
many of them are harder than they look. Individually they have
relatively low leverage. Together they might have higher leverage, but
the cost of doing them all is way higher than you'd think.
> *_Protected Methods_*
>
> Protected methods could be considered to control what can be accessed
> on interfaces.
Considered, but rejected. The semantics of protected are more subtle
than most people think.
More information about the amber-dev
mailing list