JavaOne 2012 : Oracle renouvelle son engagement à faire évoluer Java et dévoile ses plans

Version imprimable

03/10/2012, 14h09
Hinault Romaric

JavaOne 2012 : Oracle renouvelle son engagement à faire évoluer Java et dévoile ses plans

JavaOne 2012 : Oracle renouvelle son engagement à faire évoluer Java et dévoile ses plans
les préversions de JDK 8 et JavaFX Scene Builder 1.1 disponibles

JavaOne 2012, la plus grande conférence annuelle autour de la plateforme Java se déroule actuellement à San Francisco.

Oracle a profité de l’occasion pour dévoiler sa feuille de route pour Java et renouveler son engagement à faire évoluer le langage afin de rassurer les utilisateurs sceptiques face aux récentes découvertes de failles dans la plateforme.

Pendant ces prochains mois, Oracle travaillera essentiellement sur Java SE 8. Au menu : l’éditeur prévoit l’intégration des expressions lambda, du moteur JavaScript Nashorn (déjà disponible dans la préversion de NetBeans 7.3), les annotations, la nouvelle API « date and time » et bien plus.

Oracle a également officialisé le projet Sumatra, qui vise à mettre fin à l’utilisation des bibliothèques externes pour l’accélération GPU des applications Java ainsi qu’au processus de conversion entre Java et OpenCL (librairie multiplateforme qui permet d'utiliser les processeurs graphiques pour réaliser des calculs lourds). Le projet Sumatra sera disponible avec Java SE 8.

http://idelways.developpez.com/news/...dk8-jigsaw.png

La préversion du JDK 8 peut déjà être testée sur le site java.net. La sortie de la version finale est prévue pour septembre 2013. On va regretter cependant le report à Java 9 du projet Jigsaw, qui devait ajouter au langage un système de module.

Java EE 7 (l’édition pour entreprise) est annoncé pour avril 2013 et apportera comme nouveautés : une API WebSocket, l’API JCACHE pour une mise en cache temporaire des objets Java, un modèle de programmation pour applications Batch et une API pour la manipulation des données au format JSON. Avec cette version de Java EE, Oracle proposera Glassfish 4.0 comme plateforme de référence.

En ce qui concerne sa plateforme de développement d’Applications Internet Riches JavaFX, Oracle envisage de passer de JavaFX 2.0 (la version actuelle) à JavaFX 8 lorsque sortira le JDK 8. Cette version de JavaFX disposera par défaut au niveau de l’interface utilisateur d’une boite à outils pour Java SE 8 Embedded. Une nouvelle API sera proposée pour la création d’interfaces utilisateur avec un meilleur support des balises HTML5, WebView et JavaFX Scene Builder 2.0.

JavaFX Scene Builder, l’outil de mise en page visuelle pour la plateforme JavaFX, qui permet aux utilisateurs de créer des interfaces utilisateur en glissant et en positionnant les composants à partir d'une palette dans une scène est actuellement disponible en version 1.1 développeur avec un support pour Linux 32 et 64 bits.

Toutes ces annonces montrent l’engagement d’Oracle à vouloir faire évoluer l’écosystème Java.

:fleche: Télécharger la préversion de JDK8

:fleche: Télécharger la préversion de JavaFX Scene Builder 1.1

:fleche: La couverture de JavaOne par Bouye

Source : JavaOne 2012

Et vous ?

:fleche: Que pensez-vous de ces annonces d'Oracle ?
03/10/2012, 15h56
la.lune

L'importance dans JavaFX8 c'est le support 3D en vrai et le support aussi de l'embarqué. Et vu que presque les syntaxe vont évolué vers Java 8 avec les expressions tous se nouveautés, de plus JavaFX sera une partie intégrant du jdk pas besoin d'installer un jre en plus du jre de java, voilà pourquoi ça va passer à la place de la version 3 à la version 8 pour aller avec java 8
03/10/2012, 21h51
bouye

Note : pour l'API Time & Date, l'équipe a dit hier soir qu'il ne sont pas à 100% sûrs de finir à temps d'ici aux deadlines imposées (j'en ai entendues deux distinctes : novembre et février, sans savoir précisément ce à quoi elles correspondent exactement).
04/10/2012, 00h25
Voyvode

Je suis globalement très emballé par ce que nous réserve le JDK 8, mais suis-je le seul à avoir un avis mitigé sur les expressions lambdas ?

J'ai cherché après plusieurs exemples sur la toile et en résumant (grossièrement) j'ai remarqué que cela permettait de simplifier le code, notamment en remplaçant les @Override pas beaux. Sauf que des parenthèses sorties de nulle part avec Java, ça ne me plaît pas beaucoup. :mrgreen:

Pourriez-vous partager votre avis et, éventuellement, me rassurer ? :calin: :mrgreen:
04/10/2012, 01h25
bouye

Grosso-modo là ils utilisent la même syntaxe que C#.
Perso, je préférais la syntaxe de JavaFXScript/Visage (note : le langage fonctionnel de JavaFX 1.0) où les closures s'écrivaient comme de bêtes pointeurs de fonction à la C, c'était bien plus simple à appréhender.

Mais bon... Un type de la team langage disait il y a 2 jours que, pour les lambda, ils avaient fait le choix de ne pas exposer les méthodes comme ayant des types à part entière, donc...
04/10/2012, 14h09
ithel

Citation:

Envoyé par Voïvode

Je suis globalement très emballé par ce que nous réserve le JDK 8, mais suis-je le seul à avoir un avis mitigé sur les expressions lambdas ?

J'ai cherché après plusieurs exemples sur la toile et en résumant (grossièrement) j'ai remarqué que cela permettait de simplifier le code, notamment en remplaçant les @Override pas beaux. Sauf que des parenthèses sorties de nulle part avec Java, ça ne me plaît pas beaucoup. :mrgreen:

Pourriez-vous partager votre avis et, éventuellement, me rassurer ? :calin: :mrgreen:

L'intérêt des expressions lambda va bien au delà; par exemple auparavant quand on voulait ajouter un ActionListener anonyme à un bouton on était obligé d'écrire:

Citation:

bouton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
/* do something */}
}
});

Avec les lambdas on aura plus qu'à déclarer le /* do something /* dans le addActionListener, tout le reste (la déclaration de la classe et de la méthode) sera déduit. Résultat un code plus simple à écrire et à lire.

Par ailleurs l'API Collection va être revue pour tirer parti de cette nouvelle manière d'écrire du code: il sera alors possible de manipuler des collections de données très facilement sans avoir à écrire de boucles for.
Par exemple: supprimer tous les objets d'une liste dont l'attribut x sera égal à 1 pourra être réalisé en une petite ligne de code ;)
04/10/2012, 16h29
Voyvode
Citation:

Envoyé par bouye

Grosso-modo là ils utilisent la même syntaxe que C#.
Perso, je préférais la syntaxe de JavaFXScript/Visage (note : le langage fonctionnel de JavaFX 1.0) où les closures s'écrivaient comme de bêtes pointeurs de fonction à la C, c'était bien plus simple à appréhender.

C'est ce que j'ai cru voir, mais je n'ai pas vraiment d'avis là-dessus dans la mesure où Visage m'avait très moyennement emballé (même s'il y avait une certaine élégance dans la syntaxe).

À ce propos, il me semble avoir lu quelque part que les lambda Java ne seront pas tout à fait des closures…

Citation:

Envoyé par ithel

L'intérêt des expressions lambda va bien au delà […] on aura plus qu'à déclarer le /* do something /* dans le addActionListener, tout le reste (la déclaration de la classe et de la méthode) sera déduit. Résultat un code plus simple à écrire et à lire.

Un truc de ce genre ?
Code:

1 2 3 bouton.addActionListener(() -> { /* do something */ });
Mais… il se passera quoi avec un MouseListener ou un KeyListener qui contiennent plusieurs méthodes à surcharger ?

Citation:

Envoyé par ithel

Par ailleurs l'API Collection va être revue pour tirer parti de cette nouvelle manière d'écrire du code: il sera alors possible de manipuler des collections de données très facilement sans avoir à écrire de boucles for.
Par exemple: supprimer tous les objets d'une liste dont l'attribut x sera égal à 1 pourra être réalisé en une petite ligne de code ;)

Là je suis entièrement pour ! La verbosité de Java ne me dérange pas trop dans l'ensemble mais devoir se palucher les tris de Collection est effectivement pénible.
04/10/2012, 16h57
ithel

Tout à fait, un truc de ce genre ;)
Et effectivement pour que cela fonctionne il faut que l'interface utilisée (ici ActionListener) ne contienne qu'une seule méthode. Donc pour un MouseListener ou un KeyListener on fera comme avant: on implémentera ces interfaces à l'ancienne (ou on étendra MouseAdaptor / KeyAdaptor 8-)).
04/10/2012, 20h42
bouye

On peut pas faire

Code:

x, y -> ...

?

C'est con si c'est figé à un seul argument :aie:
05/10/2012, 09h53
ithel

Citation:

Envoyé par bouye

On peut pas faire

Code:

x, y -> ...

?

C'est con si c'est figé à un seul argument :aie:

Si bien sûr on peut avoir autant d'arguments que l'on souhaite. Pour plus d'information vous pouvez aller voir l'article "Java 8 et les Lambda" sur le blog de la société Zenika.
05/10/2012, 16h54
bouye

Ma faute, j'avais lu en diagonale en essayant de comprendre la manière de calculer les impôts sur le revenu américain qui nous était expliquée durant la dernière session :aie:

Oui donc il parlait de plusieurs méthodes et non pas plusieurs arguments. :mrgreen:

Ouaip c'est un peu pour ça que je trouve le truc moins efficace que les closures où il fallait juste transmettre le nom d'une fonction qui correspondait au type attendu. Ici, il faut utiliser une interface avec une seule méthode, c'est pas pratique pour tous les mouse et keyboard listener de AWT/Swing/JavaFX. :P

Concernant les interfaces avec plusieurs méthodes, il est surement probable que de nouvelles interfaces voient le jour comme pour try-with-resource.

Par exemple :
Code:

1 2 3 4 5 6 7 8 9 interface WindowGainedFocusListener extends EventListener { void windowGainedFocus(WindowEvent e); } interface WindowLostFocusListener extends EventListener { void windowLostFocus(WindowEvent e); } interface WindowFocusListener extends WindowGainedFocusListener, WindowLostFocusListener {}
Sinon sur la page du JEP 109: Enhance Core Libraries with Lambda (JDK Enhancement Proposal) :

Citation:

Envoyé par JEP 109: Enhance Core Libraries with Lambda

Candidate Survey
[...]
Another approach is to look through existing Java code – both within the library and outside, e.g. from the Qualitas Corpus – and do pattern matching or synthesis to discover candidates. A set of techniques might be as follows:
[...]

Identify abstract classes with one or two abstract methods, and consider adding constructors or factories that takes lambdas. Also consider this for interfaces. The pattern is where implementation is to be “filled in” via overriding; consider how to convert this into passing a Lambda as a parameter.

Ce qui devrait donner quelquechose comme :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 interface WindowEventListener { void windowEventOccured(WindowEvent e); } class WindowFocusAdapter implements WindowFocusListener { public static WindowFocusListener newWindowFocusGainedListener(WindowEventListener listener) { return new WindowFocusAdapter() { void windowGainedFocus(WindowEvent e) { listener.windowEventOccurs(e); } }; } public static WindowFocusListener newWindowFocusLostListener(WindowEventListener listener) { return new WindowFocusAdapter() { void windowLostFocus(WindowEvent e) { listener.windowEventOccurs(e); } }; } public static WindowFocusListener newWindowFocusListener(WindowEventListener listener) { return new WindowFocusAdapter() { void windowGainedFocus(WindowEvent e) { listener.windowEventOccurs(e); } void windowLostFocus(WindowEvent e) { listener.windowEventOccurs(e); } }; } void windowGainedFocus(WindowEvent e) {} void windowLostFocus(WindowEvent e) {} }
Le plus probable sera certainement la dernière "Factory method". Surtout que la plupart (la totalité ?) des listener AWT/Swing à plusieurs méthodes, il est possible de tout gérer dans la même méthode car l’évènement porte les indications nécessaires.

En tout cas l'API Java SE 8 ne mentionne rien du genre, il est possible que AWT/Swing n'évolue pas contrairement à JavaFX qui est censé être la relève.

20/12/2012, 15h25
Hinault Romaric

Oracle sort la Preview de Java SE 8 pour ARM

Oracle sort la Preview de Java SE 8 pour ARM
avec JavaFX, les développeurs peuvent créer des applications pour Raspberry Pi

Mise à jour du 20/12/2012

Près de deux mois après la sortie de la préversion de Java SE 8, lors de la conférence JavaOne, Oracle publie une déclinaison de la plateforme de développement pour ARM.

La préversion de Java SE 8 pour ARM va permettre de développer des applications Java pour les systèmes embarqués et autres dispositifs reposant sur l’architecture ARM à l’instar du Raspberry Pi. Elle embarque une version de JavaFX (sur Linux), le framework de développement d’Applications Internet Riches.

Pour rappel, Java SE 8 introduira comme nouveautés : les expressions lambda, le moteur JavaScript Nashorn, les annotations, la nouvelle API « date and time » et bien plus.

La sortie de la version finale de la plateforme est prévue pour septembre 2013.

http://idelways.developpez.com/news/...dk8-jigsaw.png

:fleche: Télécharger Java SE 8 pour ARM

Source : Oracle

Et vous ?

:fleche: Qu'en pensez-vous ?
20/12/2012, 19h00
Gugelhupf
J'ai remarqué que les lambdas de Java 8 ressemblaient à celui de C++11.

Sympa d'inclure un Joda Time dans le standard.
Par contre j'aurai bien aimé qu'il y est les dates au format relatif.
Quelque chose du genre :
Code:

1 2 // Premier Mercredi du moins prochain DateTime d = new DateTime("first Wednesday of next month");
Pourrait-t-on avoir des informations plus précises sur les différentes nouveautés cités ?
21/12/2012, 10h00
adiGuba

Citation:

Envoyé par bouye

Ouaip c'est un peu pour ça que je trouve le truc moins efficace que les closures où il fallait juste transmettre le nom d'une fonction qui correspondait au type attendu. Ici, il faut utiliser une interface avec une seule méthode, c'est pas pratique pour tous les mouse et keyboard listener de AWT/Swing/JavaFX. :P

Le problème avec cette solution, c'est qu'elle ne s'applique pas bien à toutes les interfaces, et que cela pourrait engendrer des erreurs "bizarres".

En effet : que faire avec les méthodes non implémentées ?
:arrow: leur attribuer un corps "vide" ?
:arrow: remonter une exception (UnsupportedOperationException) ?

Si cela laisse le corps vide, ca marche bien avec les listeners, mais cela peut aboutir à des cas incohérent pour d'autre type d'interface. Image une méthode "add(E)" qui ne fasse rien. Tu penses stocker ton objet mais il n'en est rien !

Si cela remonte une exception, cela permet de détecter immédiatement le problème, mais cela empêche l'utilisation dans des listeners...

De même : que faire lorsqu'elles retournent une valeurs ?
:arrow: retourner une valeur "nulle" (null, false, 0, 0.0 selon le cas)
:arrow: retourner une exception ?

Bref dans tous ces cas là il est préférable d'adapter l'API avec une interface "mono-méthode"...

a++
21/12/2012, 11h35
adiGuba
Au passage je viens de découvrir une petit modif anodine mais bien sympathique dans l'API Logger.

En général on effectue un log de la manière suivante :

Code:

LOG.log(Level.INFO, "Message " + args);

Toutefois ce code à un défaut, c'est que le message est généré AVANT l'appel de la méthode log(), et qu'il sera donc construit en mémoire même lorsque les logs de ce niveau sont désactivé.

Pour pallier à cela on utiliser généralement un if pour vérifier le niveau :
Code:

1 2 3 if (LOG.isLoggable(Level.INFO)) { LOG.log(Level.INFO, "Message " + args); }
Dans la preview du JDK8 on peut désormais utiliser un Supplier<String> pour générer le message.
Supplier<T> est juste défini comme cela :
Code:

1 2 3 public interface Supplier<T> { public T get(); }
L'intérêt c'est qu'on peut donc utiliser une expression lambda pour la génération du message :

Code:

LOG.log(Level.INFO, () -> "Message " + args );

Du coup il est inutile de vérifier le niveau avant l'appel, puisque le message ne sera généré que lors de l'appel de la méthode get() du Supplier, et uniquement lorsque le niveau de log correspondant est activé...

a++
22/12/2012, 14h42
bouye

Heu, j'ai toujours du mal avec leur notation à savoir à quel moment sont faits les allocations des closures/classes anonymes. Encore plus quand c'est sensé produire du bytecode compatible avec la version antérieure. Tu es bien sur de ce que tu avances ?
22/12/2012, 16h08
adiGuba
Citation:

Envoyé par bouye

Heu, j'ai toujours du mal avec leur notation à savoir à quel moment sont faits les allocations des closures/classes anonymes. Encore plus quand c'est sensé produire du bytecode compatible avec la version antérieure. Tu es bien sur de ce que tu avances ?

Oui j'ai testé cela dans l'early-access JDK8+lambda : http://jdk8.java.net/lambda/

Sinon cela ne produit pas du bytecode compatible dans le sens où il faudra à tout prix une JVM 1.8 pour faire tourner le code.

En fait le compilateur va générer une méthode statique qui contiendra le code de la lambda, et va inclure un appel dynamique vers cette méthode via l'invokedynamic et les MethodHandle.

Grosso modo le code suivant :
Code:

1 2 3 public void method(String args) { LOG.log(Level.INFO, () -> "Message " + args ); }
Va générer quelque chose de la sorte :
Code:

1 2 3 4 5 6 7 public void method(String args) { LOG.log(Level.INFO, invokedynamic bootstrap[lambda$1]); } static String lambda$1(String args) { return "Message " + args; }
Bien sûr l'instruction "invokedynamic bootstrap[lambda$1]" n'est pas du Java, mais une représentation d'un appel dynamique permettant de créer le lambda.

Lors de cet appel dynamique, la JVM va retourner un type "lambda proxy" qui "simulera" l'interface fonctionnelle (Supplier<T> dans cet exemple).
Et apparemment la JVM pourra effectuer là dessus des optimisations très importante en allant carrément jusqu'à remplacer l'appel directement dans le code à l'intérieur de la méthode appelée.

J'avoue ne pas tout comprendre bien précisément, mais cela a vraiment l'air très prometteur...

Malheureusement, il y a un "MAIS" ! Apparemment ils sont à la bourre sur l'implémentation de ce proxy lors de l'appel dynamique. Ainsi dans un premier temps l'appel dynamique va se contenter de créer une classe anonyme...

La version optimisé avec le proxy viendra plus tard...

Et si j'ai bien compris tout ceci concerne avant tous la JVM, donc il n'y aura pas besoin de recompiler...

a++
24/12/2012, 06h52
bouye

Merci de la précision :ccool:

Juste pour info, l'early-access Lambda est assez complète : http://jdk8.java.net/lambda/

Il y a de quoi bien s'amuser même si l'inference des types n'est pas finalisé (du coup il faut parfois caster explicitement, ce qui alourdit la syntaxe).

Quelques exemples vites fait :

1 - On peut effectuer des itérations internes sur les éléments Iterable :

Code:

1
2
3
4
5
6
7
8
9
10
        Iterable<String> iterable = ...
 
       // Ceci :
       for (String s : iterable) {
            System.out.println(s);
        }
       // Peut-être remplacé par cela :
        iterable.forEach((String s) -> {
            System.out.println(s);
        });

Par defaut cela revient à la même chose (c'est à dire à utiliser un Iterator), mais chaque implémentation peut définir sa propre implémentation de forEach() plus optimisé (c'est le cas par exemple d'ArrayList qui effectuera directement le parcours sur son tableau interne).

Au passage ce code peut être encore plus compacte, de diverses manières :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
        // Expression Lambda complète, dont l'expression peut prendre plusieurs lignes :
        iterable.forEach((String s) -> {
            System.out.println(s);
        });
        // Lorsque le code de l'expression se résume à une ligne,
        // on peut se passer des crochet et du point-virgule final { ... ;}
        iterable.forEach((String s) -> System.out.println(s));
        // Le type du (ou des) paramètre est déduit du contexte
        // il est donc possible de s'en passer :
        iterable.forEach((s) -> System.out.println(s));
        // Lorsqu'on n'a qu'un seul et unique paramètre,
        // on peut se passer des parenthèses :
        iterable.forEach(s -> System.out.println(s));

Mieux encore, lorsqu'on se contente d’appeler une méthode, et que sa signature correspond à l'interface fonctionnelle, on peut remplacer l'expression Lambda par un pointeur de méthode (notez bien les doubles deux-points :: )

Code:

iterable.forEach(System.out::println);

Cette méthode forEach() est encore plus intéressante sur les Map :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
        Map<String, Object> map = ...
 
        // Avec un Iterator on se ballade plein de chose inutile :
        for (Map.Entry<String,Object> e : map.entrySet()) {
            String k = e.getKey();
            Object v = e.getValue();
            System.out.println(k + " = " + v);
        }
 
        // Alors qu'on peut aller droit à l'essentiel avec les expr. lambda :
        map.forEach((k,v) -> {
            System.out.println(k + " = " + v);
        });

L'API de Collections profite des "Default Method" pour se doter de quelques méthodes utiles, exemple :

Code:

1
2
3
4
5
6
7
8
9
10
        List<String> list = ...
 
        // Passer tous les éléments de la liste en majuscule :
        list.replaceAll(String::toUpperCase);
        // Supprimer tous les éléments de moins de 4 caractères :
        list.removeAll(s -> s.length() < 4);
        // Trier les éléments selon l'ordre naturel (compareTo()) :
        list.sort(Comparators.naturalOrder());
        // Trier les éléments selon leurs tailles :
        list.sort(Comparators.comparing(String::length));

Note : cette dernière ligne ne fonctionne pas encore à cause de l'inférence des types qui n'est pas finalisé, et pour le moment il faut spécifier explicitement le paramétrage Generics, ce qui ne sera plus le cas dans la version finale :

Code:

list.sort(Comparators.<String,Integer>comparing(String::length));

Mais le plus gros ajout vient des streams : lorsqu'on utilise un stream, on peut filtrer ou modifier les valeurs de la source de données, sans modifier cette source.

Quelques exemples (loin d'être exhaustif) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
        Collection<String> coll = ...
 
        // On prend tous les éléments de 6 caractères,
        // en ignorant les doublons,
        // que l'on va trier par taille,
        // puis convertir en majuscule,
        // pour finalement afficher les valeurs :
        coll.stream()
                .filter(s -> s.length() < 6)
                .uniqueElements()
                .sorted(Comparators.<String, Integer>comparing(String::length))
                .map(String::toUpperCase)
                .forEach(System.out::println);
 
        // Même chose que ci-dessus, mais en stockant le résultat dans une ArrayList :
        List<String> result = coll.stream()
                .filter(s -> s.length() < 6)
                .uniqueElements()
                .sorted(Comparators.<String, Integer>comparing(String::length))
                .map(String::toUpperCase)
                .into(new ArrayList<String>());
 
        // Afficher seulement 5 éléments, après le 10ième
        // (cela permet de mettre en place un système de pagination)
        coll.stream()
                .slice(10, 5)
                .forEach(System.out::println);
 
        // Recherche de la valeur minimum, selon l'ordre naturel :
        String min = coll.stream()
                .min(Comparators.naturalOrder())
                .get();

La grosse force des "stream" étant de pouvoir paralléliser les traitements.
En effet il suffit d'utiliser la méthode parallelStream() à la place de stream() pour que le traitement soit effectuer en parallèle (si cela est possible bien entendu).

a++

28/12/2012, 08h23
la.lune

:merci: adiGuba

Je viens de découvrir autre chose concernant les interfaces.

Pour rappel il y a les "default methods" qui permettront d'intégrer du code dans les interfaces :
Code:

1 2 3 4 5 6 7 public interface Demo { public void method1(); public default void method2() { System.out.println("method2"); } }
:arrow: Les classes qui implémentent cette interface pourront se contenter d'implémenter la méthode method1().
La méthode method2() est optionnelle et utilisera le code par défaut si elle n'est pas implémenté par la classe.

Mais ce n'est pas tout, on pourra utiliser des méthodes private, destiné à être utiliser dans les "default methods" afin de pouvoir mutualiser le code.
Par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public interface Demo { public void method1(); public default void method2() { this.print("method2"); } public default void method3() { this.print("method3"); } private void print(String text) { System.out.println(text); } }
Enfin les interfaces pourront contenir des méthodes static :
Code:

1 2 3 4 5 public interface Demo { public static void method() { /* ... */ } }
Attention toutefois car à l'heure actuelle ceci n'est implémenté que dans le compilateur. En clair cela va compiler normalement, mais cela risque de générer des erreurs à l'exécution...

Sources :
Enhancement: Add support for static interface methods
Enhancement: Add experimental support for private (instance) interface methods

a++

30/12/2012, 19h04
adiGuba
Citation:

Envoyé par la.lune

Là on vient d'apprendre l'ajout du mot clé "default"

C'est le principe des "default's methods" qui permet de définir une implémentation par défaut dans une interface. Les classes qui l'implémente n'auront pas l'obligation d'implémenter la méthode.

Cette notion a eu plusieurs noms, et j'en ai pas mal parlé sur mon blog :
- Evolution des interfaces avec les « public defenders methods »
- « Extension Methods » de C# 3.0 VS « Defender Methods » de Java 7
Citation:

Envoyé par la.lune

mais peut-on avoir une méthode par défaut et static aussi?

Cela n'a pas de sens.
Les méthodes static d'une interface ne sont pas hérité ni rien. Elle doivent impérativement être appelé via la syntaxe NomDeLinterface.method().

a++
31/12/2012, 14h37
Gugelhupf

Différence entre nouvel interface et les classes abstraites ?

Bonjour,

abiGuba, quels seront les différences entre ces interfaces et une classe abstraite ?

Est-ce que c'est semblable aux Traits et Mixins ?

Comment résoudre le problème d'héritage multiple si une classe implémente 2 interfaces qui contiennent une méthode defaut avec le même nom mais un contenu différent ?
31/12/2012, 14h51
kinaesthesia

Citation:

Envoyé par Gugelhupf

Bonjour,

abiGuba, quels seront les différences entre ces interfaces et une classe abstraite ?

Est-ce que c'est semblable aux Traits et Mixins ?

Comment résoudre le problème d'héritage multiple si une classe implémente 2 interfaces qui contiennent une méthode defaut avec le même nom mais un contenu différent ?

Ca ne compilera pas tout simplement car le compilo te dira automatiquement que ta classe fille qui implémente les deux interfaces possèdes deux fois la même méthodes ;-)
31/12/2012, 15h37
Gugelhupf

Ça parait logique de ce point de vue, mais alors pourquoi la compilation est autorisée en C++ ? ...

Aussi quel différence y a-t-il maintenant entre une interface et une classe abstraite ?
Pour moi une interface était une classe 100% abstraite, je vais devoir changer ma définition de la chose.

Citation:

Envoyé par Gugelhupf

abiGuba, quels seront les différences entre ces interfaces et une classe abstraite ?

Les interfaces ne peuvent pas contenir d'état car elles ne peuvent pas contenir d'attribut d'instance.

Citation:

Envoyé par Gugelhupf

Est-ce que c'est semblable aux Traits et Mixins ?

Oui cela s'en approche beaucoup.

Citation:

Envoyé par Gugelhupf

Comment résoudre le problème d'héritage multiple si une classe implémente 2 interfaces qui contiennent une méthode defaut avec le même nom mais un contenu différent ?

S'il n'y a aucun lien entre les deux interfaces, cela provoquera une erreur de compilation. Il faudra alors l'implémenter.
On peut bien sûr se contenter de réutiliser une implémentation d'une interface via une syntaxe spécifique, par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 interface A { public default void method() { System.out.println("A::method"); } } interface B { public default void method() { System.out.println("B::method"); } } class C implements A, B { public void method() { A.super.method(); } }
Par contre les règles sont plus souples, car si la méthode est implémenter dans une classe parente, cela prendra toujours la priorité sur les méthodes par défaut, qui comme leur nom l'indique, ne seront utilisé QUE dans le cas où la classe ne possèdent pas d'implémentation.

Là où cela est très intéressant, c'est que la résolution de la méthode est géré par la JVM au runtime. C'est à dire que cela permet d'ajouter une méthode à une interface sans avoir à recompiler toutes les classes qui l'implémentent...

Citation:

Envoyé par Gugelhupf

Ça parait logique de ce point de vue, mais alors pourquoi la compilation est autorisée en C++ ? ...

Les règles d'héritage du C++ et de Java sont très différente.
En Java toutes les méthodes sont implicitement virtuelles et donc hérités par défaut, alors que c'est exactement l'inverse en C++.
Du coup les problèmes que l'on peut rencontrer via l'héritage multiple sont moins visible...

a++

Citation:

Envoyé par adiGuba

Mieux encore, lorsqu'on se contente d’appeler une méthode, et que sa signature correspond à l'interface fonctionnelle, on peut remplacer l'expression Lambda par un pointeur de méthode (notez bien les doubles deux-points :: )

Code:

iterable.forEach(System.out::println);

J'ai une question ici, d'abord je comprend bien le comportement de cette expression, mais ma question c'est que veux-tu dire par 'interface fonctionnelle'? Tu peux détailler un peu pour qu'on comprenne le concept, je vais être un peut claire, si j'ai une interface que j'ai crée et une méthode static avec paramètre un objet, dont " iterable" itère sur une une collection de ces objets. alors peut-on faire cet astuce?

Je donne un code exemple:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public class A{ ..... } public interface I { public static void methode(A a){ ..... }}//interface I //Et puis dans un traitement peux-je faire: Iterable<A> iterable = ... iterable.forEach(I::methode)
Je pense que ma question est claire

01/01/2013, 21h51
adiGuba
@la.lune
Réponse courte : oui ton code fonctionne ;)

Réponse longue :

Une interface fonctionnelle c'est juste une interface qui ne contient qu'une seule et unique méthode abstraite (sans compter les "default's methods" donc), comme par exemple Runnable.

Les lambdas et les références de méthode ne peuvent être convertis qu'en une interface fonctionnelle, à condition que leurs signatures correspondent.

Par exemple dans ce cas là la méthode Iterable::forEach() est définie comme ceci :
Code:

1 2 3 4 5 public default void forEach(Block<? super T> block) { for (T t : this) { block.accept(t); } }
Et Block fait partie du package java.util.function, qui inclut un ensemble d'interface fonctionnelle basique...
Grosso-modo elle est définie comme ceci :
Code:

1 2 3 4 5 public interface Block<T> { public void accept(T t); }
Et c'est la signature de cette méthode qu'il faudra donc respecter avec la lambda (ou la référence de méthode).

Si tu références une méthode static, alors la signature de cette méthode devra correspondre à la signature de l'interface. C'est le cas dans ton exemple donc cela marchera bien ;)

Après tu as encore le cas particulier des méthodes d'instances, où tu as deux possibilités :
- Si tu références une méthode d'instance via son type, et la signature est alors modifié en rajoutant le type en tant que premier paramètre, ce qui permettra de passer l'instance lors de l'appel.
- Si tu la référence via une instance d'un objet, la signature n'est pas modifié et l'appel se fera sur l'instance indiqué.
Exemple Object::toString pourra être associer avec une interface fonctionnelle tel quel celle-ci :
Code:

1 2 3 public interface Exemple { public String method(Object o); }
A l'inverse pour une instance d'objet "o", o::toString sera associable avec une interface fonctionnelle comme ceci :
Code:

1 2 3 public interface Exemple { public String method(); }
Je ne sais pas si tout est bien clair...

a++
01/01/2013, 23h10
la.lune

Oui j'ai compris en grog, même si j'avais fait juste fait une erreur en oubliant le mot "void" pour methode(..).

Mais là encore juste pour plus de précision, je me demande quelle est l'interface référencé ici quand tu dis "Si tu références une méthode static, alors la signature de cette méthode devra correspondre à la signature de l'interface", En quelle interface fonctionnelle la lamba sera converti?(l'interface dont sa signature correspond à celle de ma méthode static) Je n'ai pas bien saisi, où est la correspondance exactement?

Aussi, je suis je suis un peu perdu quand tu parles de correspondance entre signature de méthode et signature d'interface, ou bien tu veux parler de correspondance entre signature de méthode et signature de la méthode de l'interface fonctionnelle.

L'exemple que tu as donné c'est sur une interface fonctionnelle déjà existante, est ce le cas pour les autres? Ce que je n'arrive pas à saisir. Sur tes premières réponses tu parles de méthodes générés dynamiquement, donc si je ne me trompe pas, est-ce ma référence de méthode sera converti dynamiquement en interface fonctionnelle lors de la compilation?

Citation:

Envoyé par la.lune

Aussi, je suis je suis un peu perdu quand tu parles de correspondance entre signature de méthode et signature d'interface, ou bien tu veux parler de correspondance entre signature de méthode et signature de la méthode de l'interface fonctionnelle.

Oui je voulais bien parler de la signature de la méthode de l'interface fonctionnelle.

Une lambda (ou une référence de méthode) ne peut être associé qu'à une interface fonctionnelle, et il faut que la signature correspondent à celle de la méthode :

Par exemple :

Code:

ActionListener listener = (ActionEvent e) -> System.out.println("ActionEvent = " + e);

:arrow: L'expression lambda a la signature suivante : "void(ActionEvent)", ce qui correspond à la signature de la méthode de l'interface fonctionnelle ActionListener qui défini la méthode suivante :

Code:

public void actionPerformed(ActionEvent e);

Au passage le "Type Inférence" rentre en jeu, ce qui nous permet de ne pas spécifier le type du paramètre dans la lambda :

Code:

ActionListener listener = (e) -> System.out.println("ActionEvent = " + e);

Et c'est la même chose pour les références de méthode. Si on a une méthode définie comme ceci :
Code:

1 2 3 public static void onEvent(ActionEvent e) { ... }
On peut l'associer à un ActionListener puisque la signature de la méthode concorde bien à la signature void(ActionEvent) :

Code:

ActionListener listener = MaClasse::onEvent;

S'il s'agit d'une méthode d'instance :
Code:

1 2 3 4 5 6 public class MaClasse { public void doSomething(ActionEvent e) { ... } }
On ne peut pas l'associer comme cela puisque l'instance se rajoute à la signature, qui devient void(MaClasse,ActionEvent).

Code:

ActionListener listener = MaClasse::doSomething; // ERREUR

Pour que la signature corresponde, il faut lui associer une instance, par exemple :
Code:

1 2 MaClasse cls = new MaClasse(); ActionListener listener = cls::doSomething; // OK
Dans ce cas là l'instance ("cls" dans l'exemple) sera utilisée pour l'appel de la méthode, qui conserve du coup sa signature originale...

Et pour les méthodes c'est la même chose. Les méthodes qui utiliseront les lambdas n'ont rien de spécial, si ce n'est qu'elles utilisent une interface fonctionnelle. Mais même si cette notion est "nouvelle", cela ne l'est pas vraiment car l'API standard est déjà pleine d'interface fonctionnelle...

Du coup on pourra utiliser les lambdas/références de méthode avec des APIs existante, du moment qu'elles utilisent une interface fonctionnelle :
Code:

1 2 3 MaClasse cls = new MaClasse(); JButton b = new JButton(); b.addActionListener(cls::doSomething);
C'est le "Type inference" qui se chargera de vérifier le tout, c'est à dire :

Récupérer le type du paramètre de addActionListener() (qui est justement un ActionListener).
Vérifier qu'il s'agit bien d'une interface fonctionnelle (ce qui est le cas puisqu'elle ne comporte qu'une seule méthode)
Vérifier que la signature de la lambda/référence de méthode concorde bien avec la signature de la méthode de l'interface fonctionnelle.

Et en cas de surcharge, le compilo ira chercher la version de la méthode qui correspond.

A noter également l'existence de référence de constructeur (en utilisant ::new), par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 // Création d'un ThreadFactory via une classe anonyme : Executors.newCachedThreadPool(new ThreadFactory() { @Override public Thread newThread(Runnable r) { return new Thread(r); } }); // Création d'un ThreadFactory via une référence de constructeur : Executors.newCachedThreadPool(Thread::new); // Ceci utilisera le constructeur Thread(Runnable), // qui correspond à la signature de la méthode de ThreadFactory
a++

02/01/2013, 12h10
adiGuba
Autre petite subtilité que j'ai découverte aujourd'hui : de nombreuses interfaces fonctionnelles (déjà existante ou non) sont enrichies de "default's method" permettant diverses choses.

Par exemple pour trier une liste d'User par nom, on pourra utiliser le code suivant :
Code:

1 2 3 List<User> list = .... list.sort( Comparators.comparing(User::getFirstName) );
Avec Comparators.comparing() qui nous retourne un Comparator<User> basé sur le getter getFirstName().

Or l'interface Comparator est doté de nouvelle méthode permettant de créer des dérivés.

Par exemple on peut inverser l'ordre de tri très simplement :
Code:

1 2 3 list.sort( Comparators.comparing(User::getFirstName) .reverseOrder() );
Ou alors on peut enchainer plusieurs comparaisons qui seront traiter dans l'ordre.
Par exemple pour tirer par nom, prénom puis date de naissance on pourra faire ceci :
Code:

1 2 3 list.sort( Comparators.comparing(User::getFirstName) .thenComparing(User::getLastName) .thenComparing(User::getBirthday) );
a++
02/01/2013, 22h22
la.lune

:merci: pour l'éclaircissement et merci encore de nous faire part de ces nouveautés :ccool:. Pour ma question là j'ai bien compris, surtout là je vois que si tu m'avait juste répondu en précisant que la signature de ma méthode satic void methode(A) correspond exactement à la signature de la méthode de l'interface fonctionnelle qu'attend un foreach qui est void(T) j'aurais tout compris et surpasser toutes les ambiguïtés.

De plus j'ai une autre question sur la parallélisation dont tu as mentionné sur les multiples instruction dont on applique à une collection, alors quand tu dis 'si cela est possible', je me pose la question possible dans le sens où certaines instructions dépendent des précédentes ou dans le sens de la capacité de l'ordinateur de paralléliser, et là aussi il y a deux option soit de la parallélisation juste en différents thread qui serait optimisée avec les architectures multi-core ou bien de la vrai parallélisation.

Ma dernière question c'est que tu parles d'interfaces de types qui ne sont pas encore finalisés dans une de tes réponses, alors peux-tu nous donner plus de détailles sur l'objet de ces interfaces et leur domaines d'applications.
03/01/2013, 10h39
adiGuba
Citation:

Envoyé par la.lune

De plus j'ai une autre question sur la parallélisation dont tu as mentionné sur les multiples instruction dont on applique à une collection,

Juste une remarque : les opérations s'appliquent sur le flux (stream), mais n'affecte pas la collection en elle-même ;)

Citation:

Envoyé par la.lune

alors quand tu dis 'si cela est possible', je me pose la question possible dans le sens où certaines instructions dépendent des précédentes ou dans le sens de la capacité de l'ordinateur de paralléliser, et là aussi il y a deux option soit de la parallélisation juste en différents thread qui serait optimisée avec les architectures multi-core ou bien de la vrai parallélisation.

C'est juste que cela dépend des instructions que tu utilises, et de ce que tu veux faire.

Par exemple si tu veux stocker le résultat dans une collection, il faut que cette dernière soit thread-safe, car si ce n'est pas le cas cela engendrera des erreurs. Du coup même si tu choisis un stream parallel ce type d'opération sera en séquentiel par défaut (en fait c'est l'implémentation de la collection qui peut modifier cela).

Citation:

Envoyé par la.lune

Ma dernière question c'est que tu parles d'interfaces de types qui ne sont pas encore finalisés dans une de tes réponses, alors peux-tu nous donner plus de détailles sur l'objet de ces interfaces et leur domaines d'applications.

En fait c'est juste un nouveau package java.util.function qui les interfaces fonctionnelles les plus courante.

Quelques exemples :

Block<T> qui permet d'exécuter un bout de code en prenant un objet en paramètre (c'est ce qui est utiliser par forEach() par exemple) :
Code:

1 2 3 public interface Block<T> { public void accept(T t); }
Function<T, R> qui prend un paramètre T et retourne une valeur R.
Code:

1 2 3 public interface Function<T, R> { public R apply(T t); }
Predicate<T> qui permet de tester un élément.
Code:

1 2 3 public interface Predicate<T> { public boolean test(T t); }
Supplier<T> qui permet de fournir une valeur.
Code:

1 2 3 public interface Supplier<T> { public T get(); }
etc...

On y retrouve aussi des versions optimisés pour les types primitifs, ou des versions "Bi" prenant deux paramètres (et utilisé par les Map pour les clef/valeur).

Il n'y a rien d'exceptionnel là dedans, c'est juste pour fournir une base commune qui sera utilisable par tout le monde plutôt que de réécrire tout plein d'interface similaire dans chaque API ;)

a++
03/01/2013, 15h33
la.lune

:merci: pour ces réponses.
Là tu vient de m'éclairer sur ces fonctions. Merci aussi pour le lien, je vois bien les détailles sur ces fonctions. Vraiment j'ai hâte de voir la sortie de la JVM 1.8 pour commencer à coder nos programmes avec ces fonctionnalités très intéressantes, on aura à écrire peu de code, et surtout nous le fan de javafx on aura à tout simplifier lors de la sortie de Javafx 8 avec le JSE8 ( déjà la date est-elle officialisée pour quand?) . Là si j'ai bien compris à présent le boulot c'est de maîtriser aussi ces interfaces à utiliser pour écrire de bon expressions lambda(ou référence de méthode) et les autres interfaces.

On va bien voir la grande utilité dans des milliers de lignes de codes qui seront réduits disons jusqu’à 40% (possible). De plus ceci permettra aussi de bien structurer l'architecture du programme, on crée les interfaces( et leur implémentation si on) à part et fait les traitement à part en faisant référence aux méthodes. En tout cas c'est une évolution marquante du langage.

Il y a un nouveau build du JDK8/Lambda : http://jdk8.java.net/lambda/

Je n'ai pas vraiment eu le temps de le parcourir, mais l'interface Map s'est enrichie de plusieurs méthodes par défaut, en plus du forEach() dont j'avais déjà parlé !
Rien d'extraordinaire en soit, mais quand même des méthodes bien utile :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
	/*
	 * Supprime un couple clef/valeur,
	 * seulement si le couple existe.
	 */
	map.remove("KEY", "VALUE");
 
	/*
	 * Remplace la valeur associé à la clef,
	 * seulement si cette clef existe déjà.
	 */
	map.replace("KEY", "NEWVALUE");
 
	/*
	 * Remplace la valeur d'un couple clef/valeur
	 * seulement si le couple existe.
	 */
	map.replace("KEY", "VALUE", "NEWVALUE");
 
	/*
	 * Remplace toutes les valeurs de la Map,
	 * par le résultat de l'expression.
	 * Exemple : mettre toutes les valeurs en Majuscule :
	 */
	map.replaceAll((k,v) -> v.toUpperCase());
 
	/*
	 * Ajoute un couple clef/valeur,
	 * seulement si la clef n'est pas déjà présente.
	 */
	map.putIfAbsent("KEY", "VALUE");
 
	/*
	 * Permet de récupérer ET de modifier
	 * la valeur d'une clef dans la Map.
	 */
	String value = map.compute("KEY", (k,v) -> v.toUpperCase());
 
	/*
	 * Permet de modifier la valeur d'une clef,
	 * seulement si le couple clef/valeur existe.
	 */
	String value = map.computeIfPresent("KEY", (k,v)->"new value");
 
	/*
	 * Permet de définir la valeur d'une clef,
	 * lorsque le couple clef/valeur est absent.
	 * Sinon on récupère la valeur existante.
	 */
	String value = map.computeIfAbsent("KEY", (k)->"empty");

A noter que ce "computeIfAbsent()" nous permettra d'implémenter une MultiMap en un rien de temps :

Code:

1
2
3
4
5
6
7
8
9
10
class MultiMap<K,V> extends HashMap<K,Collection<V>> {
 
	private Collection<V> creator(K key) {
		return new ArrayList<>();
	}
 
	public void add(K key, V value) {
		this.computeIfAbsent(key, this::creator).add(value);
	}
}

:arrow: L'appel add(K,V) permettra d'ajouter l'élément "value" dans la collection, en la créant si neccessaire.

a++

Bonjour,

Je lu l'article sur la syntaxe des lambdas (écrit par adiGuba).

1. J'aurais aimé savoir s'il y avait une différence entre le fait de préciser le type d'un argument ou non :
Code:

1 2 3 4 5 // On ne précise pas le int (x) -> x + 1 // On précise le int (int x) -> x + 1
2. Aussi, si on utilise un lambda dans une classe, pourra-t-on automatiquement avoir accès au this dans le lambda (sans avoir à le faire passer par un paramètre) ?

En C++11 ou PHP5.3 il est possible de faire passer des variables externes au bloc lambda, on fait alors la distinction entre fonction anonyme et fermeture du lambda.

En C++11 par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 // On retourne x + y [](int x, int y) -> int { return x + y; }; // On retourne x + y + z (z variable extérieur au bloc lambda) int z = 10; [z](int x, int y) -> int { return x + y + z; };
En PHP5.3 par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 <?php // On retourne x + y function($x, $y){ return $x + $y; }; // On retourne x + y + z (z variable extérieur au bloc lambda) $z = 10; function($x, $y) use ($z){ return $x + $y + $z; };
3. Qu'en est-t-il du Java pour les fermetures (utilisation de variable extérieur au bloc lambda) ?

Merci :)

20/01/2013, 16h16
adiGuba
Citation:

Envoyé par Gugelhupf

1. J'aurais aimé savoir s'il y avait une différence entre le fait de préciser le type d'un argument ou non :

Il n'y a aucune différence. S'il n'est pas précisé le type est déduite selon le contexte par le compilateur...

Citation:

Envoyé par Gugelhupf

2. Aussi, si on utilise un lambda dans une classe, pourra-t-on automatiquement avoir accès au this dans le lambda (sans avoir à le faire passer par un paramètre) ?

Oui, tout simplement en utilisant this :

Code:

Runnable r = () -> this.method();

Citation:

Envoyé par Gugelhupf

3. Qu'en est-t-il du Java pour les fermetures (utilisation de variable extérieur au bloc lambda) ?

C'est tout à fait possible :
Code:

1 2 3 4 5 6 // On retourne x + y IntBinatyOperator op1 = (x, y) -> x + y; // On retourne x + y + z (z variable extérieur au bloc lambda) int z = 10; IntBinatyOperator op1 = (x, y) -> x + y + z;
La seule restriction c'est que la variable doit être implicitement final.
C'est à dire que la variable doit être définie et ne doit pas être modifié dans la lambda ou en dehors...

a++
20/01/2013, 21h23
Gugelhupf

Merci beaucoup adiGuba :ccool:

Fuseau horaire GMT +2. Il est actuellement 02h18.

Partenaire : Hébergement Web