Interface Related Improvements

[Brian Goetz]

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.