Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (575)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Someone brought up an interesting topic regarding the new JDK8 default methods.  (Read 992 times)
0 Members and 1 Guest are viewing this topic.
Offline tom_mai78101
« Posted 2014-02-08 07:48:38 »

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?
Offline nerb
« Reply #1 - Posted 2014-02-08 08:46:39 »

That person who brought up this topic states that this is multiple inheritances, something that Java has been avoiding since its origins.

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...
Offline Spasi
« Reply #2 - Posted 2014-02-08 08:48:13 »

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).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nerb
« Reply #3 - Posted 2014-02-08 08:57:38 »

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() Huh
Offline Spasi
« Reply #4 - Posted 2014-02-08 09:12:34 »

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

1  
2  
3  
4  
@Override
public void foo() {
   B.super.foo();
}
Offline Roquen
« Reply #5 - Posted 2014-02-08 10:30:40 »

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.
Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #6 - Posted 2014-02-08 11:48:11 »

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.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Roquen
« Reply #7 - Posted 2014-02-08 12:01:51 »

Got lambas?  And that's the tip of the iceberg.
Offline Spasi
« Reply #8 - Posted 2014-02-08 12:03:39 »

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.

Assuming this is the example you're referring to:

1  
2  
3  
4  
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.
Offline tom_mai78101
« Reply #9 - Posted 2014-02-08 18:05:50 »

Quote from: 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.

Does default methods break this "binding contract"?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pjt33
« Reply #10 - Posted 2014-02-09 16:16:45 »

Assuming this is the example you're referring to:

1  
2  
3  
4  
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).
You're half-right. comparing is a normal static method, but thenComparing is a default method.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (35 views)
2014-10-17 03:59:02

Norakomi (25 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (26 views)
2014-10-15 16:18:58

TehJavaDev (50 views)
2014-10-14 00:39:48

TehJavaDev (50 views)
2014-10-14 00:35:47

TehJavaDev (40 views)
2014-10-14 00:32:37

BurntPizza (63 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (75 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!