What should default interfaces be for?

[Brian Goetz]

We've known for a while that while the primary motivation for this feature was to provide a mechanism for interface evolution, that it would be widely recognized in short order that default methods effectively would constitute "traits-lite".  And we're OK with that.  This is an upgrade to the inheritance model and enables a lot of nice things that were not possible before.  I've spent the last few months using default methods to develop library prototypes and it is quite a pleasant improvement -- it offers a "right" place to put a lot of code that didn't have a right place before. I hope others on this list have done the same (the single most valuable thing that this community can do to help is to *try it out and give concrete feedback*.)

We have spent a great deal of time thinking through where this feature could or could not go in the future, and tuning the design so as not to foreclose on useful future directions.  (For example, all of the items on Stephen's list below have been considered in depth.)  

However, keep in mind that the goal is not "add traits to Java", and not only is that out of scope for Lambda, but is simply impractical to consider as a deliverable for Java 8.  And, realistically, there are a lot of decisions that were already made in the past (such as the fact that the default for interfaces is that methods are public and fields are private and final) that make it far more difficult to "take it all the way".  So it is quite likely that where we are now is mostly where we'll end up, with a few rough edges filed down (such as possibly adding nonpublic methods.)  

A significant factor in designing this feature is compatibility.  Many otherwise good-seeming ideas end up creating annoying compatibility issues.  The "trait interface" example Stephen suggests is a good example of this; when last we analyzed this (which to be fair was before we made some significant simplifications in the model, and its possible that these aspects may have changed), there were several subtle issues this introduced, making some seemingly harmless changes (like changing an ordinary interface to a trait interface) either source- or binary- incompatible.  

So, to sum up, while we support the trait-like use of interfaces with default methods, and have done a great deal of work to ensure that they remain useful when used in this manner, we're all going to have to recognize that there are going to be limitations to how far we can take it.  It is one of those glass half-full or half-empty things; you can be happy that we have a bunch of new trait-like features, or complain that it was not taken as far as it could be.  


On Mar 13, 2012, at 3:18 AM, Stephen Colebourne wrote:

> On 13 March 2012 00:10, David Holmes <david.holmes at oracle.com> wrote:
> David said:
>> I'm concerned that default methods are being seen as a new way to
>> construct type hierarchies, rather than just being a short-term way to
>> add a new method to an existing interface. In my opinion developers who
>> subclass interfaces to which default methods get added, should implement
>> those new methods in the next version of their libraries/apps - so that
>> they don't rely on implicit use of defaults (they can make it explicit
>> if it suits their needs). Default methods provide an evolution path for
>> interfaces, but they can very easily be mis-used.
> 
> I think that in all the focus on lambdas, there hasn't been enough
> discussion of what the Java community wants from the defaulted
> interfaces feature.
> 
> David expresses the original lambda-focussed opinion - that default
> methods in interfaces solely exist to provide a mechanism for
> interface evolution. A necessary evil to provide the ability to
> integrate lambdas into existing APIs but not for general use as part
> of API design.
> 
> I've come to the opposite opinion. That defaulted interfaces are a
> major new language feature in their own right, and should be
> celebrated as such. I want to use them as a new way of designing
> applications, replacing most usages of abstract classes today,
> providing much of the feature set asked for by "abstract enums" and
> effectively treating them as Java's traits. IMO, the addition of
> traits is as important to API design as lambdas themselves.
> 
> What we need is a debate on the feature. Do we, as users/developers,
> want the minimal feature set necessary to support lambdas, or the
> maximal feature set that would occur were we adding traits to Java?
> 
> Things that may be options with a fully implemented feature:
> - private-scoped methods
> - package-scoped methods (would probably require adding a package
> keyword for scope)
> - protected-scoped methods
> - static methods
> - what should the default scope be
> - whether the name "default interface" is the best choice ("trait interface"?)
> 
> So, please chime in on whether you think default interfaces should be
> kept simple and minimal (as David suggested), or be thought of as a
> major new feature in their own right? (Try to initially focus on the
> big question without too much low-level detail)
> 
> Stephen
>