Final defenders

Yuval Shavit yshavit at
Wed Aug 8 08:07:14 PDT 2012

As one of the grumblers (to some extent), I have to say I agree with Brian.
This seems to me like a (big) step towards a fuller defaults-as-traits
implementation, and that's a good thing. Non-public methods are icing on
the cake that I would welcome if they came in a future release, but I don't
think they're show-stoppers. Final defenders are potentially dangerous, so
I'm happy we're not rushing into them.

Full disclosure here: I've never programmed in Scala, just read a book a
couple years ago. But the chapter about traits, and the order in which
they're resolved and executed, just seemed unnecessarily complex. It's a
turn-off, and we should avoid that sort of "everything under the sun, but
it's very hard to grasp" approach. If that means being somewhat
incremental, so be it.

The only thing I would ask of Oracle -- and I think they're doing it
already -- is to keep defaults-as-traits in the back of their heads, and
design defender methods such that they can be evolved into a fuller
implementation of traits in the future.

On Wed, Aug 8, 2012 at 10:47 AM, Brian Goetz <brian.goetz at> wrote:

> And you have gotten exactly what you wished for.  That's exactly what this
> feature adds -- multiple inheritance of behavior.  Of course we understand
> that people will use them as traits.  And we've worked hard to ensure that
> the the model of inheritance they offer is simple and clean enough that
> people can get good results doing so in a broad variety of situations.  We
> have, at the same time, chosen not to push them beyond the boundary of what
> works simply and cleanly, and that leads to "aw, you didn't go far enough"
> reactions in some case.  But really, most of this thread seems to be
> grumbling that the glass is merely 98% full.  I'll take that 98% and get on
> with it!
> On Aug 8, 2012, at 4:19 AM, C.J. Kent wrote:
> > I agree with Stephen. Interfaces with defender methods provide enough
> trait-like features that developers (including me) will use them as traits.
> It doesn't make any difference whether or not the people on this list think
> it's a good idea.
> >
> > I think my experience is fairly typical of corporate Java devs and I'm
> struggling to think of examples where the ability to evolve an interface
> would've been useful. But I've often wished for multiple inheritance of
> behaviour.
> >
> > Chris
> >
> > On 8 Aug 2012, at 11:56, "Stephen Colebourne" <scolebourne at>
> wrote:
> >
> >> On 8 August 2012 11:37, Talden <talden at> wrote:
> >>> On Wed, Aug 8, 2012 at 9:49 PM, Stephen Colebourne <
> scolebourne at> wrote:
> >>>> Where there is no doubt in my mind is that I will use traits (in
> >>>> whatever form they are provided) for far, far more than interface
> >>>> evolution when JDK8 is released.
> >>>
> >>> This paragraph stood out to me.  The wording is important.
> >>
> >> Let me reword then.
> >>
> >> A new feature is being added to JDK8 - default method implementations
> >> in interfaces.
> >> Some are trying to state that this should only be used for interface
> evolution.
> >> I am stating that I will use it for multiple-inheritance/trait-like
> >> behaviour, far, far more than interface evolution.
> >>
> >> More broadly, I'm saying that interface evolution is only occasionaly
> >> an issue I face. And yes, this new feature will be useful for
> >> interface evolution, but that won't be its prime use for me.
> >>
> >> Having established the above, it is clear to me that it would be far
> >> better to have a properly designed fuller implementation, than suffer
> >> from the hamstrung API designs we will see (like the "do" method
> >> prefix) without the fuller trait-like feature.
> >>
> >>> It seemed that what you were really saying was "...that I will use
> >>> interface default methods to implement traits far, far more...". I say
> >>> that because you cannot say that you will 'use traits' when they're
> >>> not on offer - you can only state an intent to use the offered
> >>> features in an unintended way.
> >>
> >> I'm advocating that the "unintended way"/"misuse" argument will be
> >> ignored, and this feature will get used far beyond the original
> >> intent. There is nothing I can see that Oracle can do to prevent that.
> >>
> >> Stephen
> >>
> >
> >

More information about the lambda-dev mailing list