Someone brought up an interesting topic regarding the new JDK8 default methods.

General Discussions
#1

Care to share your opinions?

Draft of the Default Methods reference documentation.

One could argue that default methods in interfaces made interfaces and abstract classes the same. That person who brought up this topic states that this is multiple inheritances, something that Java has been avoiding since its origins.

As for me, I’m not sure as to what the implementation of default methods are going to be used, as the draft itself is still in beta stages. Possibly, it might have different behaviors between abstract methods, or possible have something new. Am I right in this?

#2

Is it? I can’t really see how it is??? I just skimmed through the article; have I missed the mark?

EDIT: …hang on… maybe I see what you are getting at now…

#3

The difference is that default methods are stateless. You can think about them as static methods with an implicit “this” parameter, than can be called on instances of the interface. This is a limited* version of “extension methods”, a popular feature in modern languages (see C#, Kotlin, Xtend).

Ambiguity can arise with default methods, for example when you have a diamond shaped inheritance tree, but that can easily be resolved. It’s nowhere close to the complexity of real multiple inheritance and has none of its drawbacks.

  • Limited, because extension methods can be added to any class (not just interfaces) at any time/scope (outside the class definition).
#4

Would someone care to humour the noob in me for a moment?

So if I have a class A with method foo(), and an interface B with default method foo(), and class C which extends A and implements B, what happens when I call c.foo() ???

#5

The foo from A would be called, because normal methods take precedence over default methods. You can override this in C, by using:

@Override
public void foo() {
	B.super.foo();
}
#6

In another way: Java’s always had multiple inheritance of type and never had multiple inheritance of state. Default methods don’t change that. They allow less PITA of design and the ability to add functionality to interfaces across versions. Currently adding functionality requires making a breaking change (not an option for the JDK for instance) or artificially introducing a new type. Both of these options suck.

#7

That example that turns the Comparator interface into a Builder feels… misguided.

Wouldn’t it be better to simply add a separate ComparatorBuilder library class?

If the main purpose of default methods is so that existing interfaces can be expanded without breaking binary compatibility, then I feel it’s somewhat pointless as most interfaces shouldn’t be able to provide a meaningful default implementation.
It’ll just result in messy interface bodged with empty implementations and warning comments.

#8

Got lambas? And that’s the tip of the iceberg.

#9

[quote=“Abuse,post:7,topic:46645”]
Assuming this is the example you’re referring to:

myDeck.sort(
    Comparator
        .comparing(Card::getRank)
        .thenComparing(Comparator.comparing(Card::getSuit)));

These are not default methods, they are normal static methods which can now be added to interfaces with Java 8. A default implementation is not provided; the implementation is being passed in via a method handle (it could also be a lambda expression).

As to having a different builder/factory class vs static methods in the interface, it’s just a matter of style I guess. My personal preference would be static in interface; more compact, a single source file, don’t have to remember the builder class name.

#10

[quote=Accname]It did not have multiple inheritance of type since you do not “inherit” from an interface. When implementing an interface you sign a binding contract to provide access to certain methods. You do not inherit anything.
[/quote]
Does default methods break this “binding contract”?

#11

[quote=“Spasi,post:9,topic:46645”]
You’re half-right. comparing is a normal static method, but thenComparing is a default method.