Discussion :

[adiGuba]

Sauf que tu peux implémenter plusieurs interfaces, alors que tu ne peux hériter que d'une seule classe...

+1
Sans oublier que les classes abstraites peuvent avoir un état via leurs attributs, alors que les méthodes par défaut ne peuvent que se baser sur le contrat de l'interface.


Bref les interfaces continueront toujours de définir un contrat.
Les méthodes par défaut pourront proposer des implémentations partielles basé sur ce contrat.

Les classes (abstraites ou pas) permettent toujours de définir une implémentation concrète, en gérant un état via les attributs...




Maintenant c'est sûr que les méthodes par défaut pourront remplacer avantageusement certains classes abstraites qui ne géraient pas d'état (je pense pas exemple à AbstractCollection).




L'autre force des méthodes par défaut, c'est surtout de pouvoir faire évoluer les interfaces existantes !
L'interface Map gagne une bonne dizaine de méthode

a++

[Matthieu Vergne]

Java 8, je te passe la bague au doigt... Enfin j'aimerais, mais hélas je dois faire attention à ce que mes programmes tournent encore sous Java 6 au boulot... Mais bon Dieux ce que ça me démange d'y passer ! {>.<}

[bouye]

Le JDK 8 u5 est disponible depuis le 15 avril. Cette mise à jour ne contient que des correctifs liés à la sécurité.

[aurelien360]

L'usage des interfaces comme types fonctionnels introduit malgré tout une certaine lourdeur syntaxique lors de l'appel d'une fonction. Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Function<String, String> laPuissanceDeLaFonc = String::toUpperCase;
 
System.out.println( laPuissanceDeLaFonc.apply("tion") );    // TION

C'est le passage par cette méthode intermédiaire qui n'est pas trop naturel. (cf. argumentation détaillée sur http://au.arena.free.fr/blog/index.p...fonctionnelles )

On aurait plutôt attendu qqch comme laPuissanceDeLaFonc("tion") comme en CAML ou Scala par exemple. Mais bon... en contrepartie les méthodes par défaut des interfaces du package 'java.util.function' apportent des mécanismes intéressants comme des types composés (ex: méthodes andThen ).

[adiGuba]

C'est le passage par cette méthode intermédiaire qui n'est pas trop naturel. (cf. argumentation détaillée sur http://au.arena.free.fr/blog/index.p...fonctionnelles )

On aurait plutôt attendu qqch comme laPuissanceDeLaFonc("tion") comme en CAML ou Scala par exemple.

Je peux comprendre que cela puisse "choquer" si on est habitué à utiliser des langages comme CAML ou Scala qui intègre ces notions...

Tu peux peut-être trouver cela "pas trop naturel", mais c'est juste la manière dont on appelle une méthode en Java.
Ton laPuissanceDeLaFonc("tion") est peut-être plus court, mais il en devient aussi plus ambigüe...


Ce choix d'implémentation est justement un des points que j'apprécie particulièrement dans les lambda de Java :

• Très peu de modification syntaxique (si ce n'est la déclaration de la lambda en elle même bien sûr).
• Pas de "type-fonction", donc pas de nouveau type à gérer, et pas de distinction entre un "type-fonction" et un objet.
• Et donc une rétrocompatibilité implicite avec un grand nombre de librairie existante, puisque le concept d'interface fonctionnelle existait déjà même si on ne le nommait pas.

a++

[aurelien360]

Ce choix d'implémentation est justement un des points que j'apprécie particulièrement dans les lambda de Java :

• Très peu de modification syntaxique (si ce n'est la déclaration de la lambda en elle même bien sûr).
• Pas de "type-fonction", donc pas de nouveau type à gérer, et pas de distinction entre un "type-fonction" et un objet.
• Et donc une rétrocompatibilité implicite avec un grand nombre de librairie existante, puisque le concept d'interface fonctionnelle existait déjà même si on ne le nommait pas.

1)Assez d'accord avec les points ci-dessus. Il est certain que "en contexte" (contraintes de compatibilité, introduction d'un nouveau paradigme sur un paradigme existant...), ces choix se défendent probablement. J'ajouterai encore et en plus l'intérêt des méthodes par défaut qui embarquées au niveau des types fonctionnels.

2)Dans l'absolu cette fois, ce n'est pas tant la comparaison syntaxique avec d'autres langages comme Scala ou CAML mais plutôt la divergence conceptuelle avec la théorie derrière (lambda calcul ou simplement en math). Une fonction n'est pas définie et manipulée de cette manière.

CONCL: Je pense que ces deux remarques se défendent de manière légitime.

[tomlev]

L'usage des interfaces comme types fonctionnels introduit malgré tout une certaine lourdeur syntaxique lors de l'appel d'une fonction. Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Function<String, String> laPuissanceDeLaFonc = String::toUpperCase;
 
System.out.println( laPuissanceDeLaFonc.apply("tion") );    // TION

C'est le passage par cette méthode intermédiaire qui n'est pas trop naturel. (cf. argumentation détaillée sur http://au.arena.free.fr/blog/index.p...fonctionnelles )

On aurait plutôt attendu qqch comme laPuissanceDeLaFonc("tion") comme en CAML ou Scala par exemple. Mais bon... en contrepartie les méthodes par défaut des interfaces du package 'java.util.function' apportent des mécanismes intéressants comme des types composés (ex: méthodes andThen ).

Je développe en C#, où les delegates s'utilisent aussi avec la syntaxe laPuissanceDeLaFonc("tion") (en réalité c'est juste un raccourci syntaxique pour laPuissanceDeLaFonc.Invoke("tion")), mais l'approche choisie par Java ne me choque pas. C'est un peu moins concis, mais ça a l'avantage de montrer clairement ce que fait la fonction, même si le développeur a choisi un nom de variable pas très clair.