Découvrons Java 8 ensemble !

Je ne me suis jamais intéressé à Java FX, mais il ne faut pas oublier qu'il va être intégré dans le JDK8 et qu'il est destiné à remplacer AWT/Swing.


On peut trouver une présentation ici : http://docs.oracle.com/javafx/2/swing/jfxpub-swing.htm


Cela semble vraiment pas mal :

• Une toute nouvelle API pour concevoir des applications graphiques.
• Possibilité de concevoir ses applications en pure Java (à-la-Swing), via des fichiers XML ou via un éditeur visuel (JavaFX Scene Builder)
• Un support intégré de feuile de style (CSS) pour customiser l'apparence de l'application.
• Un support de certains format audio (MP3, AIFF/PCM, WAV/PCM, AAC) et vidéo (FLC, H.264/AVC).
• Une gestion intégré des animations.
• Un composant WebView basé sur Webkit et permettant d'afficher de l'HTML moderne (avec des bouts d'HTML5 dedans).
• Un nouveau composant Swing nommé JFXPanel, qui permet d'intégrer du JavaFX au sein d'une application Swing !

a++

Sans oublier qu'on peut facilement l'intégrer dans des Canvas SWT, ou directement faire des vues dans une application Eclipse grâce au projet e(fx)clipse. Le pont entre Swing et SWT était un point délicat, c'est bien que ça évolue !

Les annotations @Repetables en Java 8 !

Citation:

---

Envoyé par adiGuba

Cela semble vraiment pas mal :

• Une toute nouvelle API pour concevoir des applications graphiques.
• Possibilité de concevoir ses applications en pure Java (à-la-Swing), via des fichiers XML ou via un éditeur visuel (JavaFX Scene Builder)
• Un support intégré de feuile de style (CSS) pour customiser l'apparence de l'application.
• Un support de certains format audio (MP3, AIFF/PCM, WAV/PCM, AAC) et vidéo (FLC, H.264/AVC).
• Une gestion intégré des animations.
• Un composant WebView basé sur Webkit et permettant d'afficher de l'HTML moderne (avec des bouts d'HTML5 dedans).
• Un nouveau composant Swing nommé JFXPanel, qui permet d'intégrer du JavaFX au sein d'une application Swing !

---

Ça, c'est ce qui existe déjà dans JavaFX 2.x (JDK 6 et 7).
Dans les nouveautés de JavaFX 8, on peut inclure :

• Un nouveau CSS par défaut encore plus proche de Bootstrap : Modena (contre Caspian pour le précédent).
• Support de l'impression.
• L’arrivée des vraies primitives 3D (box, cylinder, sphere et mesh) ainsi que de tout ce qui est textures et gestion des éclairages et de la caméra.
• Le support de Swing dans JavaFX (via la classe SwingNode).
• La possibilité de merger l'EDT et la JavaFX Application Thread.
• Un ou deux nouveaux contrôles (DatePicker, TreeTable mais manque toujours FormattedTextField et Spinner).
• Le code spaghetti a base de listeners, event handlers et autre callbacks va devenir plus lisible grâce aux lambda (side-effect passage a JDK 8).

Liste complète ici (je n'ai pas linké la partie 2 de l'article qui est plus une whishlist du rédacteur qu'autre chose)

Merci !

Même si je survole ton thread d'info sur JavaFX de temps en temps, je suis loin de connaitre la chose.

Pour moi tout JavaFX est "nouveau".
Surtout que si j'ai bien compris ce sera enfin réellement en standard dans le JRE. Non ?


a++

Citation:

---

Envoyé par adiGuba

Mais le plus fort là dedans, c'est que le code devient par la même occasion parallélisable !
En effet il suffit d'ajouter .parallel() dans le flux d'appel des méthodes du Stream pour que les traitements soient parallélisé...



a++

---

Sachant que ce qui ralentit le code, ce sont les IOs, dans ce cas là j'ai du mal à voir l'intérête de la parallélisation. Par contre, j'aimerais savoir où tu le place, l'appel à parallel, dans toute cette tartine :)

Officiellement oui, même si c'est de facto le cas depuis "je ne sais plus quelle version de" Java 7 (la 1ere version est celle publiee a la JavaOne 2011 il me semble). Dans Java 7, les runtimes etaient dan jre/lib tandis que dans Java 8 elles passent dans jre/lib/ext et sont donc tout le temps sur le classpath.

Citation:

---

Envoyé par tchize_

Sachant que ce qui ralentit le code, ce sont les IOs, dans ce cas là j'ai du mal à voir l'intérête de la parallélisation.

---

Oui tout à fait mon exemple n'est pas forcément des plus parlant.

J'imaginais juste un cas où le traitement serait également lui-même assez "long" pour une raison quelconque.
Par exemple si dans User.parse() on tente de vérifier la validité de chaque email auprès d'un serveur de mail...

Citation:

---

Envoyé par tchize_

Par contre, j'aimerais savoir où tu le place, l'appel à parallel, dans toute cette tartine :)

---

N'importe où avant l'opération terminale (collect() ici)

Les Streams comportent deux types de méthodes :

• Les méthodes intermédiaires, qui retournent toujours un Stream modifié (mais qui n'effectuent pas encore le traitement). C'est le cas de filter/map/parallel...
• Les opérations terminales, qui vont effectuer tout le traitement en prenant en compte chaque méthodes intermédiaires qui l'ont précédé.

Tout le traitement est exécuté uniquement lors de l'appel de la méthode terminale.

Citation:

---

Envoyé par bouye

Officiellement oui, même si c'est de facto le cas depuis "je ne sais plus quelle version de" Java 7 (la 1ere version est celle publiee a la JavaOne 2011 il me semble). Dans Java 7, les runtimes etaient dan jre/lib tandis que dans Java 8 elles passent dans jre/lib/ext et sont donc tout le temps sur le classpath.

---

Donc on pourra l'utiliser directement sans rien faire de particulier. Cool :D


a++

Citation:

---

Envoyé par adiGuba

N'importe où avant l'opération terminale (collect() ici)

Les Streams comportent deux types de méthodes :

• Les méthodes intermédiaires, qui retournent toujours un Stream modifié (mais qui n'effectuent pas encore le traitement). C'est le cas de filter/map/parallel...
• Les opérations terminales, qui vont effectuer tout le traitement en prenant en compte chaque méthodes intermédiaires qui l'ont précédé.

---

Je n'en doutz pas, mais comme je ne connais pas encore tout ça, si je demandais l'exemple, c'est parce que je n'ai aucune idée de comment parallel s'utilise. Et ta réponse ne m'aide pas ^^. Par exemple, si j'écrit, en mettant "n'importe où" le parallel:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

return Files.lines(file, StandardCharsets.ISO_8859_1) // On supprime les espaces inutiles .map( String::trim ) // On ne prend pas les lignes vides .filter( line -> !line.isEmpty() ) // On ne prend pas les lignes commençant par # .filter( line -> !line.startsWith("#") ) // On convertit le tout en User .map( User::parse ) .parallel() // Et on ne prend que les User sans email .filter( u -> u.getEmail() == null ) // Enfin on récupère le tout dans une ArrayList : .collect( Collectors.toCollection(ArrayList::new) ); }

---

Est-ce que ce sont les opération de parsing qui vont avoir lieu en parallèe? Est-ce que c'est l'ensemble des opérations précédentes qui vont avoir lieu en parallèle? Et si oui, chaque opération intermédiaire aura sa collection de threads, ou il y aura une collection de trhread qui traitera séquentiellement l'ensemble des opérations précédente, genre un thread par ligne du fichier.
Est-ce que c'est l'opération filter( u -> u.getEmail() == null ) qui est parallélisée, ou tout ce qui se trouve juste après le parallel?


Et si j'écrit:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

return Files.lines(file, StandardCharsets.ISO_8859_1) // On supprime les espaces inutiles .map( String::trim ) // On ne prend pas les lignes vides .filter( line -> !line.isEmpty() ) // On ne prend pas les lignes commençant par # .filter( line -> !line.startsWith("#") ) .parallel() // On convertit le tout en User .map( User::parse ) .parallel() // Et on ne prend que les User sans email .filter( u -> u.getEmail() == null ) .parallel() // Enfin on récupère le tout dans une ArrayList : .collect( Collectors.toCollection(ArrayList::new) ); }

---

Ca se comporte comment?

tchize,

J'ai écrit un petit papier là dessus. A la fin des trucs sur les foncteurs :
http://caron-yann.developpez.com/tut...osures-java-8/

Je pense, mais ça reste une supposition que ça va fonctionner comme suit :
Chaque fonction d'ordre supérieur (fonction qui accepte un foncteur, comme map / filter / reduce (fold pour les puristes)) créer un Thread, le thread lit les éléments d'une blocking queue en entrée et déverse le résultat dans une blocking queue en sortie.

Voilà ce que ça donne visuelement :
http://caron-yann.developpez.com/tut...589FF6574E.png


Après comme dit ce n'est qu'une supposition. C'est comme ça que je l'ai implémenté dans mon tuto. Mais je pense que ça ne doit pas être loin de ce qu'il a été fait dans le jdk 8

Ca ne m'aide pas en fait (et j'ose espérer que le foncteurs ne créent pas de thread par défaut), ce que je demande, c'est quand on fait un parallel, il agit sur quoi :)

Je ne sais pas du tout ! Peu-t-être qu'il indique à la fonction d'ordre supérieur (précédente ou suivante) de faire ça justement.
Il faut que je regarde d'un peu plus prêt.
Je vais de toutes façon devoir le faire avec ma petite lib de FRP. :ccool:

Citation:

---

Envoyé par tchize_

Je n'en doutz pas, mais comme je ne connais pas encore tout ça, si je demandais l'exemple, c'est parce que je n'ai aucune idée de comment parallel s'utilise. Et ta réponse ne m'aide pas ^^. Par exemple, si j'écrit, en mettant "n'importe où" le parallel:

---

C'est le dernier qui sera pris en compte (sachant qu'on peut faire l'inverse avec un sequential())
En fait cela ne fait que changer un état du Stream, qui ne sera pris en compte que lors du traitement terminale (via collect() dans l'exemple).
Donc le répéter plusieurs fois n'a aucun intérêt.

En fait en théorie c'est à la création du Stream que l'on devrait définir cela (l'API de Collections dispose d'ailleurs de deux méthodes stream() et parallelStream()). Les méthodes sequential() ou parallel() permettent juste de forcer l'un ou l'autre selon nos besoins dans le cas où l'on ne maitrise pas forcément la création du Stream...

Citation:

---

Envoyé par tchize_

Est-ce que ce sont les opération de parsing qui vont avoir lieu en parallèe? Est-ce que c'est l'ensemble des opérations précédentes qui vont avoir lieu en parallèle? Et si oui, chaque opération intermédiaire aura sa collection de threads, ou il y aura une collection de trhread qui traitera séquentiellement l'ensemble des opérations précédente, genre un thread par ligne du fichier.

---

Oui si le Stream est parallélisé lors de l'appel de la méthode terminale, c'est l'ensemble de ses opérations qui le seront.

En fait chaque opération intermédiaire permet de configurer le Stream. Mais le code associé ne sera vraiment exécuté que lors de l'appel de la méthode terminale.

En cas d'exécution parallèle, les threads se partageront les données (selon l'implémentation de la méthode), mais chaque thread s'occupera de la totalité des opérations sur une même donnée.



Les Streams sont en quelques sortes des Iterators que l'on peut configurer.
Toutefois tant qu'on n'appelle pas une méthode terminale les données ne sont pas parcouru...


a++

Donc on ne peux pas avoir une partie séquentielle, car non parallélisable, mais rapide, suivi d'une partie lente mais parallélisée?

J'avais mal compris, je pensais que chaque méthode filter() et autre renvoyait un nouveau stream, et que les stream étaient chainés entre eux pour réaliser l'objectif final.

Citation:

---

Envoyé par tchize_

Donc on ne peux pas avoir une partie séquentielle, car non parallélisable, mais rapide, suivi d'une partie lente mais parallélisée?

J'avais mal compris, je pensais que chaque méthode filter() et autre renvoyait un nouveau stream, et que les stream étaient chainés entre eux pour réaliser l'objectif final.

---

Je pense que tu peu en utilisant des collectes intermédiaires pour construire la liste.

Citation:

---

Envoyé par tchize_

Donc on ne peux pas avoir une partie séquentielle, car non parallélisable, mais rapide, suivi d'une partie lente mais parallélisée?

---

Non.
Mais en même temps j'ai du mal à voir un cas concret qui ne serait pas parallélisable en dehors de l'opération "terminale".

Citation:

---

Envoyé par tchize_

J'avais mal compris, je pensais que chaque méthode filter() et autre renvoyait un nouveau stream, et que les stream étaient chainés entre eux pour réaliser l'objectif final.

---

C'est bien cela : filter() et cie renvoient un autre stream (qui englobe le précédent).
Mais il y a quand même un état unique pour la parallélisation qui sont commun à tous les streams (en fait les stream englobant utilise l'état du stream initial).
Les streams sont ensuite chainé lors de l'appel de la méthode "terminale".

Je ne pense pas que mélanger les deux soit pratique ou utile (les threads risque d'attendre la fin de partie séquentielle plus qu'autre chose).


a++

Citation:

---

Envoyé par adiGuba

Non.
Mais en même temps j'ai du mal à voir un cas concret qui ne serait pas parallélisable en dehors de l'opération "terminale".

---

J'ai une liste de nombres, disons un très grosse liste. Je dois effectuer les opération suivantes:

1) vérifier que le nombre se trouve dans les critères d'acceptation d'une boite noire, sur laquelle je n'ai pas le contrôle ou qui est non parallélisable.
*On pourrait imaginer une boite dont le critère est l'espacement entre ce nombre est le précédent est au moins égal à deux fois l'espacement précédent accepté.
*Ou une boite qui se connecte à une service web, où on n'a qu'une licence, donc on ne peux envoyer qu'une seule requête à la fois
2) on calcule la valeur d'une fonction complexe en ce point, nécessitant de faire tourner un thread pendant 2 secondes, par exemple
3) on collecte les résultats


Donc pour moi, le 2 va aller moins vite que le 1, mais le 1 ne peux pas être parallélisé. Par contre si la boite noire en 1 nécessite des accès réseau, elle gagnerais à pouvoir tourner en // avec 2, tout en ne traitant qu'un nombre à la fois. Donc à faire une collection intermédiaire, on perdrait du temps.

Dans ton exemple, Adiguba, il est clair que la lecture du fichier est séquentielle, donc on ne peux rien paralléliser derrière?

Citation:

---

Envoyé par adiGuba

Les Streams sont en quelques sortes des Iterators que l'on peut configurer.
Toutefois tant qu'on n'appelle pas une méthode terminale les données ne sont pas parcouru...

---

un problème avec le modèle des Itérateurs c'est qu'il y a un producteur et un consommateur et le modèle ne prévoit pas que le consommateur puisse dire au producteur "j'arrête tu peux fermer boutique". Est-ce que cet aspect est pris en compte dans les Streams (sont ils Closeable ?)

Citation:

---

Envoyé par tchize_

Donc pour moi, le 2 va aller moins vite que le 1, mais le 1 ne peux pas être parallélisé. Par contre si la boite noire en 1 nécessite des accès réseau, elle gagnerais à pouvoir tourner en // avec 2, tout en ne traitant qu'un nombre à la fois. Donc à faire une collection intermédiaire, on perdrait du temps.

---

Je dirais qu'il suffirait de synchronisé la tache 1.
Ainsi elle ne s'exécuterait bien qu'une à la fois, tout en permettant à d'autre thread d'effectuer les tâches suivantes (ou d'attendre de pouvoir faire cette tâche).


Bref il n'y a pas besoin d'exécuter toutes les tâches 1, puis ensuite de passer aux tâches 2...

Citation:

---

Envoyé par tchize_

Dans ton exemple, Adiguba, il est clair que la lecture du fichier est séquentielle, donc on ne peux rien paralléliser derrière?

---

En interne cela utilise BufferedReader::readLine()... qui est synchronisé.
On peut donc très bien faire cela en parallèle.

Bien sûr du coup il n'y a qu'un seul thread à faire le readLine() à la fois, mais une fois qu'il ont lu une ligne il peuvent faire tous les traitements derrière pendant qu'un autre thread effectue le readLine() suivant...

Citation:

---

Envoyé par professeur shadoko

un problème avec le modèle des Itérateurs c'est qu'il y a un producteur et un consommateur et le modèle ne prévoit pas que le consommateur puisse dire au producteur "j'arrête tu peux fermer boutique". Est-ce que cet aspect est pris en compte dans les Streams (sont ils Closeable ?)

---

Les Streams implémente bien AutoCloseable donc c'est possible.
Par contre il faut utiliser un bloc try-with-ressource pour que la méthode close() soit appelée.

Mon code était donc érroné, et il aurait donc dû être le suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public static List<User> read3(Path file) throws IOException { // On récupère un Stream<String> représentant les lignes du fichier : try (Stream<String> lines = Files.lines(file, StandardCharsets.ISO_8859_1)) { return lines // On supprime les espaces inutiles .map( String::trim ) // On ne prend pas les lignes vides .filter( line -> !line.isEmpty() ) // On ne prend pas les lignes commençant par # .filter( line -> !line.startsWith("#") ) // On convertit le tout en User .map( User::parse ) // Et on ne prend que les User sans email .filter( u -> u.getEmail() == null ) // Enfin on récupère le tout dans une ArrayList : .collect( Collectors.toCollection(ArrayList::new) ); } }

---

a++

ok, en vous lisant, je me rend compte de mon erreur d'implémentation dans mon tutorial.

Je m'explique....
Ce que j'ai fait, c'est de générer une liste intermédiaire à chaque fois que l'on faisant un map / filter ou un fold. :oops:
Ce qui pose un sérieux problème d'optimisation.

Hier j'ai farfouiller un peu dans le FluentIterator de Guava. Et, j'aurai du m'en douter d'après le nom, ça ce base sur l'iterator et non sur la liste elle même.
Donc c'est un iterator qui renvoie une iterator qui renvoie un iterator ect....

Ce que je comprend maintenant de la chose, c'est que la liste est transformée en flux, et que les fonctions d'ordre transforment le flux. Une fois le flux acheminer, il faut un concentrateur pour construire la liste résultante. Malin !

Dans mon implémentation, chaque fonction d'ordre fonctionnait comme un concentrateur. (un peu comme si on faisait à chaque fois filter.collect.map.collect etc....)

Maintenant ce que je ne comprend pas bien, c'est comment dans guave (et scala), cette étape de concentration est elle masquée. Parce que je n'ai pas souvenir d'avoir eu besoin de faire une telle chose..... :aie::aie::aie::aie:

L'exploration continue....
Pour la parallelisation, je pense qu'il est possible toutefois de conserver celle que j'avais proposé, c'est à dire de paralleliser les traitements du flux plutôt que les éléments traités de la liste, comme ça semble être le cas pour J8. :P

Ha, sinon, tout ça, ça ma donner des idées pour mes petites recherche sur la FRP (qui est basé sur exactement le même principe, mais qui ce concentre sur des flux d'évènements, et de valeurs modifiés dans le temps.... tout un programme) : http://www.developpez.net/forums/d13...gramming-java/

Vala. Mais comme on dit, il n'y a que ceux qui n'essaie rien qui ne ce trompent jamais.
Merci en tous cas pour toutes ces réponses qui ont éclairé ma sombre caverne.

Pour ce parallel, je me demande s'il y aura effectivement création de thread a la demande ou s'il y aura une sorte de pool global à la JVM un peu comme en .Net (la classe ThreadPool qui s'utilise statiquement).

A première vue il semblerait que ce soit le cas.
Les threads sont nommés "ForkJoinPool.commonPool-worker-X" ce qui semble indiquer qu'ils utilisent le framework ForkJoin de Java 7 avec un pool commun.

D'ailleurs la javadoc de ForkJoinPool et ForkJoinPool.commonPool() semble le confirmer...


a++

Bon j'ai fait mes petits essais avec le JDK8. Dommage que netbeans ne reconnaisse pas déjà les lambdas.

Sinon voilà la concision obtenu avec ma petite librairie maison React4J

Code:

---

1 2 3 4 5 6 7 8

Var<String> mouseAndTime = MouseReact.button1() .map(arg1->arg1 ? "button pressed" : "button released") .toVar("no button yet !") .merge(mouseX, (arg1, arg2)->arg1 + " ( x=" + arg2) .merge(mouseY, (arg1, arg2)->arg1 + ", y=" + arg2 + ")");   label1.setText(mouseAndTime);

---

On dit merci les lambdas.... :ccool:

Citation:

---

Envoyé par CyaNnOrangehead

Dommage que netbeans ne reconnaisse pas déjà les lambdas.

---

Netbeans 7.4 les gère très bien.
J'ai fait tous mes essai avec ;)


Il te propose même de convertir les classes anonymes en lambda.


a++

Il me semblais que depuis la version 6, Netbeans essayait de suivre la numérotation des versions majeures du JDK. Bizarre qu'il ne l'ait pas nommé 8.0. Le support du JDK 8.0 est il complet?

Citation:

---

Envoyé par adiGuba

Netbeans 7.4 les gère très bien.
J'ai fait tous mes essai avec ;)


Il te propose même de convertir les classes anonymes en lambda.


a++

---

Ca vas trop vite !!!! Je ne suis jamais à jour. Terrible.
Je télécharge la bête de ce pas. :ccool: merci :ccool:
En tous cas, niveau code source ça change pas mal la donne pour utiliser ma lib. Je suis assez content. En plus comme c'est retro-compatible, ça ne m'a pas demandé beaucoup de changement.... :ccool::ccool::ccool::ccool: merci Oracle (mince je me rend compte que je ne m’imaginais jamais dire un truc pareil !!!! :aie::aie::aie::aie:)

Citation:

---

Envoyé par Uther

Il me semblais que depuis la version 6, Netbeans essayait de suivre la numérotation des versions majeures du JDK. Bizarre qu'il ne l'ait pas nommé 8.0. Le support du JDK 8.0 est il complet?

---

Aucune idée pour la numérotation.
Mais ils attendent peut-être la sortie officielle du JDK8...

Quand au support, il me semblait assez complet.
En même temps contrairement à eclipse il me semble que Netbeans utilise directement le compilateur javac du JDK...


a++

Des slides de Devoxx : "Autumn Collections, From Iterable to Lambdas, Streams and Collectors"

http://fr.slideshare.net/jpaumard/au...and-collectors


a++

Citation:

---

Envoyé par adiGuba

Des slides de Devoxx : "Autumn Collections, From Iterable to Lambdas, Streams and Collectors"

http://fr.slideshare.net/jpaumard/au...and-collectors


a++

---

Au fait ! Pour résumer ce que dit José Paumard, les lambdas permettent une programmation déclarative plutôt qu'impérative.
Ils permettent, dans le cas des listes (mais également de évènements (FRP), IO etc.) de programmer le quoi plutôt que le comment !

Dans sa démo, sa fonction de réduction calcul la somme. Il pourrait directement calculer la moyenne à l'aide d'une suite. Mais ça sous entends d'entretenir un index.

Citation:

---

Envoyé par adiGuba

Des slides de Devoxx : "Autumn Collections, From Iterable to Lambdas, Streams and Collectors"

http://fr.slideshare.net/jpaumard/au...and-collectors

---

superbe! ça c'est un exposé selon mon coeur!
la technique est expliquée par les besoins.

Je viens de tomber sur ce bout de code sur la mailling-list du projet lambda.
Il consiste à rechercher toutes les méthodes par défaut des interfaces d'un fichier jar passé en paramètre (rt.jar par exemple) :

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

public class AllDefaultMethods {   private static Class<?> loadClassFromFileName(String name) { String className = name.substring(0, name.length() - ".class".length()); try { return Class.forName(className.replace('/', '.')); } catch (Throwable t) { // skip unknown class, or LinkageError return null; } }   public static void main(String... args) throws IOException { try (JarFile jarFile = new JarFile(args[0])) { jarFile.stream() .map(JarEntry::getName) .filter(name -> name.endsWith(".class")) .map(AllDefaultMethods::loadClassFromFileName) .filter(Objects::nonNull) .flatMap(type -> Arrays.stream(type.getDeclaredMethods())) .filter(Method::isDefault) .forEach(System.out::println); } } }

---

Mis à part la méthode loadClassFromFileName(), tout est fait via l'API de Stream, via JarFile qui propose un stream() sur ses entrées (JarEntry).

Pour chaque JarEntry :

• map(JarEntry::getName) récupère le nom du fichier.
• filter(name -> name.endsWith(".class")) filtre seulement les fichiers *.class
• map(AllDefaultMethods::loadClassFromFileName) tente de charger la Class correspondante (ou renvoi null en cas d'erreur)
• filter(Objects::nonNull) permet donc d'ignorer les classes qui n'ont pas pu être chargée.
• flatMap(type -> Arrays.stream(type.getDeclaredMethods())) récupère les Methods de la classe.
• filter(Method::isDefault) filtre seulement les méthode par défaut.
• Et enfin forEach(System.out::println) affiche la méthode dans System.out

Il manque juste un filter(Class::isInterface) pour limiter la recherche de méthodes par défaut dans les interfaces...

Simple !


Pour info, en Java 7 un code similaire s'écrierait comme cela :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public static void main(String... args) throws IOException { try (JarFile jarFile = new JarFile(args[0])) { Enumeration<JarEntry> entries = jarFile.entries(); while (entries.hasMoreElements()) { String name = entries.nextElement().getName(); if (name.endsWith(".class")) { Class<?> clazz = AllDefaultMethods.loadClassFromFileName(name); if (clazz!=null) { for (Method method : clazz.getDeclaredMethods()) { if (method.isDefault()) { System.out.println(method); } } } } } } }

---

a++

abiGuda, tu te rend compte que ton second code est plus court que le premier :aie::aie::aie::aie:

Te chari. Les lambdas c'est plus élégant !
Tien jete un oeil là dessus : http://www.developpez.net/forums/d13...s-langage-sql/

Si tu remplace :
- Select par map
- Where par filter
- (orderby, max, min, count, average) par reduce

On comprend pourquoi LINQ a été mis en place et surtout sur quoi la réflexion c'est elle basée. ;)

Citation:

---

Envoyé par CyaNnOrangehead

abiGuda, tu te rend compte que ton second code est plus court que le premier :aie::aie::aie::aie:

---

Non. Il est malgré tout légèrement plus court en plus d'être plus lisible ;)
C'est juste que je n'ai pas répété la méthode loadClassFromFileName() dans le second code... mais elle y est aussi utilisé ;)


Et oui le principe des Stream est similaire à celui des requêtes SQL ;)




Sinon les "checked-exceptions" seront encore plus emmerdante avec Java 8 et les lambdas, puisqu'il faut que les interfaces fonctionnelles définissent ces exceptions pour qu'elles soient utilisable.

Par exemple, si je veux récupérer les noms/emails de certains utilisateurs afin de préparer un mailing.
Pour afficher cela sur la console il n'y a aucun soucis :

Code:

---

1 2 3 4 5 6

List<User> users = ... users.stream() .filter(User::isOptin) .filter(u -> u.getEmail()!=null ) .map(u -> u.getName() + "\t" + u.getEmail()) .forEach(System.out::println);

---

Maintenant, si je veux stocker cela dans un fichier via un Writer, je ne peux pas le faire directement car l'exception ne peut pas être utilisée dans forEach puisque l'interface Consumer ne déclare pas d'exception :

Code:

---

1 2 3 4 5 6 7 8

List<User> users = ... try (Writer out = new FileWriter("out.txt")) { users.stream() .filter(User::isOptin) .filter(u -> u.getEmail()!=null ) .map(u -> u.getName() + "\t" + u.getEmail()) .forEach(out::append); // ERROR : incompatible throws type IOException }

---

Pas cool :?


a++