Discussion :

[adiGuba]

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++

[alain.bernard]

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 !

[adiGuba]

Les annotations @Repetables en Java 8 !

[bouye]

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)

[adiGuba]

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++

[tchize_]

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

[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.

[adiGuba]

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

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.

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


a++

[tchize_]

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 :

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

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 :

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

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?

[CyaNnOrangehead]

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 :



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

[tchize_]

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

[CyaNnOrangehead]

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.

[adiGuba]

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

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++

[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.

[CyaNnOrangehead]

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.

[adiGuba]

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".

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++

[tchize_]

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?

[professeur shadoko]

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 ?)

[adiGuba]

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

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

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 :

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

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++

[CyaNnOrangehead]

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

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.

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.