[cfoley]

I was reading a blog about lambdas in Java 8. I'm really liking some of the plans. It's going a lot further than I had assumed and I'm quite excited about the release next year.
http://datumedge.blo...-8-lambdas.html

One part of the blog (which seems to be something of a tangent to lambdas) is about providing default implementations for methods in interfaces. Here is what it says:

Quote

Default methods

With Java today, it is not possible to add methods to a published interface without breaking existing implementations. Java 8 gives us a way to specify a default implementation in the interface itself:

interface Queue {
        Message read();
        void delete(Message message);
        void deleteAll() default {
                Message message;
                while ((message = read()) != null) {
                        delete(message);
                }
        }
}

Subinterfaces can override a default method:

interface BatchQueue extends Queue {
        void setBatchSize(int batchSize);
        void deleteAll() default {
                setBatchSize(100);
                Queue.super.deleteAll();
        }
}

Or a subinterface can remove the default by redeclaring the method without a body:

interface FastQueue extends Queue {
        void deleteAll();
}

Doing this forces an implementation of FastQueue to implement deleteAll().

I'm not sure how I feel about this. There have been times where I thought something like this would be useful. I mean, nonsense like MouseAdapter would be obsolete (or could be if they rework the interfaces to define empty default methods). I know these interfaces still can't store state so any methods defined must be expressed in terms of other methods but it does seem to muddy the waters between interfaces and abstract classes.

Right now I don't know what to think. It seems less principled to allow implementations but maybe more practical. I'd be interested to hear what others make of it.

[nick2price]

I think that these extension methods can only be applied to existing interfaces from the api, so I presume this means you cant use them in your own interfaces. Thats probably incorrect though! I am with you, it seems like there will be a fine line between this and abstract classes. Anyways, managed to come across this pdf which explains absolutely everything about this topic Extension Methods

[cfoley]

Thanks for the link to the PDF.

So, this is how they are adding map, fold, forEach, etc to the Collections framework, for example. They couldn't just add more methods to the interface because they would break everyone elses implementations (including my CudDownArrayList and CutDownLinkedList classes I wrote for a performane experiment once). This makes sense. They can add the methods to the interfaces and everyone else's code will still work fine.

Potential diamond inheritence problems:

Quote

If the resulting list of interfaces contains a single interface, the search is resolved
successfully; the default implementation named in that interface is the resolution.
If the resulting set has multiple items, then throw a linkage exception indicating
conflicting extension methods.

But it's OK really:

Quote

Note that conflicting defaults can only arise from inconsistent separate compilation; the compiler will
reject conflicting defaults if they are present at compile time.

After reading that PDF, I'm happier about the whole thing.

[nick2price]

The only thing I dont really like in relation to the diamond inheritence problem is

Quote

If both B and C were to override m():
interface A { void m() default X.a; }
interface B extends A { void m() default X.b; }
interface C extends A { void m() default X.b; }
class D implements B, C { }
In this case, the inheritance of m() in D would be ambiguous (because the set of mostspecific
default-providing interfaces contains both B and C). At compile time D would
be rejected unless D implements a body for m().

If interface C doesnt provide a default for m(), then D.m() resolves to X.b. If interface C did provide a default with a different value, then D.m() would resolve to this value. But because both B and C provide the same defaults, D is rejected. I think the same defaults shouldnt cause an issue, but instead D always resolves to the most recent provider. At the moment, it only works with the most recent - unique provider (there could be a logical reason for this which I am tottally missing). I also wonder what will happen if D implemented its body for m() to X.b.

After going through that pdf, it definately looks like an interesting concept, but I bet it ends up being one of those things you either love or hate. Shame we have to wait till 2013 to test it out!