What should default interfaces be for?

Richard Warburton richard.warburton at gmail.com
Tue Mar 13 08:03:27 PDT 2012

> 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

I'd imagine it would be confusing, and abusable, for people if the
scope could be different for abstract and default interface methods,
so I'd have thought any changes to scoping rules would have to be
pretty much kept in lock-step between those two.

> - static methods

I don't at all see a motivating case for a static method on an
interface.  Perhaps I've missed something, maybe you could provide
some examples.  I think in fact that examples would help this
discussion along in general.

> - what should the default scope be

I also don't see how you could change the default scope for abstract
methods without introducing backwards compatibility and can imagine no
end of confusion arising if it were different between abstract and
default methods.  I consequently wouldn't see this as desirable.

> - whether the name "default interface" is the best choice ("trait interface"?)

How much does the name matter?

Given that there were some vague mentions of more features on default
methods after the completion of JSR 335, it would be good to know if
any of these have been discussed by the Expert Group.  Importantly
have any of them have been directly rejected, or have any of them had
specific objections to their inclusion noted?

Also was anything else discussed as a possible characteristic of
default methods?  Obviously the more general you make interfaces, the
closer you get to a complete multiple implementation inheritance which
seems like an unpopular idea.  So is the goal to stop here, or
possibly in future move a bit further towards that line, albeit
without getting there?



More information about the lambda-dev mailing list