What should default interfaces be for?

[Gregg Wonderly]

I've long wondered about the basics of JDBC Driver support.  It's always been 
the case that different versions of drivers have continued to work with newer 
APIs being available, and the appropriate runtime exception regarding 
unimplemented methods gets thrown.  This has
to do with the fact that the Driver was compiled with an appropriate version of 
the driver interface, while applications may be compiled with another version 
visible.  At class loading time, no verification gets done, or at least missing 
methods are disregarded.

What is it about extending interfaces that makes this kind of behavior a 
non-start, and default methods perceived as the better answer?  I am not sure 
that I understand how a default method can always be "correct", for all uses of 
an old implementation by a class using the new definition.

Gregg Wonderly

On 3/14/2012 1:47 PM, Anthony Vanelverdinghe wrote:
> I dislike the idea of allowing implementation inside interfaces, so I
> see default methods as a necessary evil for interface evolution. And I
> fully agree with the view that developers should not implicitly depend
> on default methods. Even more: why not let the Java compiler emit a
> warning when classes do depend on default methods?
>
> PS: in case it wouldn't be clear by now: I 'm against allowing Object
> methods as default methods :)
>
> Kind regards, Anthony
>
>
> Op 13/03/2012 11:18, Stephen Colebourne schreef:
>> 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
>>
>
>