I never really did see what was wrong with multiple inheritance. I’ve got a bunch of code in several different places… why can’t I compose them all into one class? Interfaces have always been useless degenerate contracts - just a bunch of method signatures and a “name”.
Cas 
The problem I always saw with multiple inheritance is variable with same name. What happen when you inherit a lot of variable from 2 or more class and many of them have the same name?
I always thought that the simple answer would be to alias any conflicts, or be explicit. Much like the hackery in the new default interface conflict stuff in Java now.
Cas
Actually looking at mixins, yes, that’s probably more like what I’d like to see.
Cas
I’d also go further, and say that it should be impossible to expose fields and private methods outside of a class. If a subclass or mixin were to define a private method or field with the same name, then it would be a separate field or method. So both a super and sub-class can both have the field ‘foo’, with no issues with them conflicting (since each has their own ‘foo’).
That way the only place conflicts and overriding behaviour can occur is around exposed method signatures, and so helps to avoid unexpected behaviour.
Isn’t that already the case?
Cas
Yeah your right, I had the idea that you could override a class and make fields become protected or public, like with methods.
Learn something new every day!
I don’t even think you can make a private method less private either.
Cas
Whether default-public or default-private is a better idea, I can’t say, but java certainly made a pretty damn odd choice with the default.
And BTW, you can’t make a private method public by overriding it. You’re just defining an entirely different method. Try attaching @Override and see what happens.
So basically you kids that think this is a bad idea subscribe to the: “All public interfaces, once released, shall have a fixed set of methods forever and ever, AMEN!” notion? This seems to me to add way more complexity than a trivial default method decl.
Since I’m lazy, I just grabbed a trival example from someone’s blog and sliced-and-diced it:
Today’s reversing some instance of the List interface with the Collections helper class.
List list;
//...
Collections.reverse(list);
The massively complex addition needed for integrating ‘reverse’ into List:
public interface List extends Collection
{
// all the current method defs in List
...
// Yikes, this is mind numbing!
extension void reverse() default Collections.reverse;
}
With this addition, every class in the whole-wide-world which implements “List” still auto-magically works. Yea! Now we can instead write:
List list;
//...
list.reverse();
Which, if you’re being honest, you’ll have to admit is much cleaner looking than calling a static method in a utility class. But that’s simply an added bonus. The routines in Collections know nothing about the implementation details of the given concrete class. Therefore they have to “perform the operation in the stupidest way possible ™”. But now any class which implements List can override the reverse method and it just auto-magically works ™. Progress!
So now, joe-average/student programmer don’t even need to know about the existence of the “Collections” helper class. All they need to know is that List has a ‘reverse’ method and the rest is merely an implementation detail.
For non-joe-average programmer, life is better as well. The only way to work around this issue is a huge mess of ‘instanceof’ nonsense. How is that less complex? And compared to convariant overrides, this should be a walk in the park.
All of the above is again trivial. Interesting usages remain to be seen and depend on the final spec and how it interops with lambdas.
I foresee some exceptionally devious usage of static classes to start bunging state into interfaces…
Cas
Just because I have knives in my kitchen doesn’t mean I stab myself in the face with them every night … which is not to say there aren’t a few nutters in the world! 
Just like riding motorcycles… the problem is quite often other people…
Cas
The only vector of “trickery” that comes to mind is having multiple sets of util classes with differing static methods which are used as default methods for some set of interfaces. Then using multiple classloaders for mixing-in a chosen grouping of methods. But this not really new, the only potential “advantage” is that (depending on how VM ends up performing the injection) is that the created multiple versions of a given concrete class (with a specific fully qualified name) will potentially be insured to be binary compatible.
I was taught to be careful while driving, because “everybody on the road is an idiot except you.” Does the same thing apply to programming?
It certainly does. If you’re writing library code that is.
Cas
When programming, everyone is an idiot, including me.
LOL!
Fact: everybody is an idiot except you ;D
Damn that tag.
Cas
Err, I must have screwed up, I was under the impression it was disabled in posts.
Anyway, I completely got rid of the [you]-code a few seconds ago.