IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage Java Discussion :

Tutoriel sur 50 nouvelles choses que l'on peut faire avec Java 8


Sujet :

Langage Java

  1. #1
    Responsable Java & Kotlin

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    juillet 2005
    Messages
    14 970
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2005
    Messages : 14 970
    Points : 72 956
    Points
    72 956
    Par défaut Tutoriel sur 50 nouvelles choses que l'on peut faire avec Java 8
    La société Soat, société d'ingénierie et de conseil en informatique vous propose un retour sur la session « 50 nouvelles choses que l'on peut faire avec Java 8 » présentée par José Paumard lors de la conférence Devoxx France 2014.

    http://soat.developpez.com/tutoriels...-devoxxfr2014/

    Vous pouvez profiter de ce message pour partager vos commentaires.

    Mickael
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de Developpez.com : mbaron.developpez.com
    Twitter : www.twitter.com/mickaelbaron
    Blog : mickael-baron.fr
    LinkedIn : www.linkedin.com/in/mickaelbaron
    DBLP : dblp.uni-trier.de/pers/hd/b/Baron:Micka=euml=l

  2. #2
    Membre confirmé Avatar de benratti
    Profil pro
    Inscrit en
    mai 2004
    Messages
    471
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mai 2004
    Messages : 471
    Points : 647
    Points
    647
    Par défaut
    la session est disponible sur parleys, comme toutes les sessions de devoxx france 2014

  3. #3
    Modérateur
    Avatar de wax78
    Homme Profil pro
    Chef programmeur
    Inscrit en
    août 2006
    Messages
    4 020
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Belgique

    Informations professionnelles :
    Activité : Chef programmeur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2006
    Messages : 4 020
    Points : 7 865
    Points
    7 865
    Par défaut
    Je m'étais pas trop interessé jusque la a ce java 8.

    J'avoue en voyant les exemple être bluffé par certains truc (notamment les ajout de collection) qui vont me permettre de me débarasser enfin des libraires que j'avais faites a la main (et qui avait le meme principe en plus bancale).
    (Les "ça ne marche pas", même écrits sans faute(s), vous porteront discrédit ad vitam æternam et malheur pendant 7 ans)

    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  4. #4
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par wax78 Voir le message
    J'avoue en voyant les exemple être bluffé par certains truc (notamment les ajout de collection) qui vont me permettre de me débarasser enfin des libraires que j'avais faites a la main (et qui avait le meme principe en plus bancale).
    On a beaucoup parlé des expressions lambdas, mais les méthodes par défaut sont tout aussi importante à mon avis.
    Cela permet de faire évoluer les APIs sans tout casser !


    a++

  5. #5
    Membre à l'essai
    Inscrit en
    octobre 2008
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : octobre 2008
    Messages : 4
    Points : 14
    Points
    14
    Par défaut Erreur dans l'exemple des String
    Une très légère correction (mais qui m'a sauté aux yeux).

    dans l'exemple des String il y a une erreur :
    boolean b = list.removeIf(s -> s.length() > 4) ;
    list.forEach(System.out::println); // affiche one, two, three

    le commentaire devrait être :
    // affiche one, two, four
    car la longueur de "three" = 5

    Cordialement,

  6. #6
    Membre habitué

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    125
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2007
    Messages : 125
    Points : 173
    Points
    173
    Par défaut
    Bonne idée d'avoir un aperçu des nouveautés de l'API.

    Quelques corrections :

    ConcurentHashMap a été complètement réécrite. Cette implémentation est thread-safe et n'utilise pas de lock.
    Étrange, je ne lis ça nulle part et vois que ConcurrentHashMap utilse toujours des blocs synchronized. Je pense qu'il s'agit d'une erreur, je suis curieux d'en connaître la source.

    , représente une durée entre deux instants.
    Je suppose qu'il faut mettre Duration à la place de la virgule

    , permet la gestion des fuseaux horaires.
    ... idem avec ZonedDateTime

  7. #7
    Responsable Java & Kotlin

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    juillet 2005
    Messages
    14 970
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2005
    Messages : 14 970
    Points : 72 956
    Points
    72 956
    Par défaut
    Bonjour à vous deux,

    Merci pour le feedback. Je vais regarder cela à tête reposée. Si je vois qu'il est nécessaire de demander l'avis de l'auteur je verrai avec lui.

    Mickael
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de Developpez.com : mbaron.developpez.com
    Twitter : www.twitter.com/mickaelbaron
    Blog : mickael-baron.fr
    LinkedIn : www.linkedin.com/in/mickaelbaron
    DBLP : dblp.uni-trier.de/pers/hd/b/Baron:Micka=euml=l

  8. #8
    Membre éclairé

    Inscrit en
    juillet 2008
    Messages
    232
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 232
    Points : 837
    Points
    837
    Par défaut
    Citation Envoyé par ymajoros Voir le message
    Étrange, je ne lis ça nulle part et vois que ConcurrentHashMap utilse toujours des blocs synchronized. Je pense qu'il s'agit d'une erreur, je suis curieux d'en connaître la source.
    Je ne sais pas si c'est nouveau, mais Oracle dit:
    However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access.
    http://docs.oracle.com/javase/8/docs...ntHashMap.html

    Donc il y a bien du lock-free dans ConcurrentHashMap en Java 8.

  9. #9
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2011
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : décembre 2011
    Messages : 3
    Points : 5
    Points
    5
    Par défaut
    Bonjour,

    Je suis l'auteur de cet article concernant la conférence « 50 nouvelles choses que l'on peut faire avec Java 8 » de José Paumard.
    Merci pour vos retours, ci-dessous quelques précisions concernant vos remarques.

    @marc.guillemin: Tu as entièrement raison, il s'agit d'une erreur d'inattention de ma part.
    Le résultat devrait afficher one, two, four.

    @ymajoros: Je suis d'accord avec toi concernant les termes manquants : Duration et ZonedDateTime.
    Etant présent sur ma version de l’article, il s'agit surement d'un oubli lors de la mise en page de celui-ci.
    bredelet a répondu à ta question à propos de la ConcurrentHashMap.

    Cordialement,

  10. #10
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par bredelet Voir le message
    Je ne sais pas si c'est nouveau, mais Oracle dit:

    http://docs.oracle.com/javase/8/docs...ntHashMap.html

    Donc il y a bien du lock-free dans ConcurrentHashMap en Java 8.
    ConcurrentHashMap a toujours été lock-free, et ce depuis son introduction dans Java 5 : http://docs.oracle.com/javase/1.5.0/...ntHashMap.html

    Par contre elle a bien été réécrite pour Java 8, afin de profiter des améliorations apportées par les Streams et les lambdas.
    Source : http://docs.oracle.com/javase/8/docs.../changes8.html
    New methods in java.util.concurrent.ConcurrentHashMap

    The Collections Framework has undergone a major revision in Java 8 to add aggregate operations based on the newly added streams facility and lambda expressions. As a result, the ConcurrentHashMap class introduces over 30 new methods in this release. These include various forEach methods (forEach, forEachKey, forEachValue, and forEachEntry), search methods (search, searchKeys, searchValues, and searchEntries) and a large number of reduction methods (reduce, reduceToDouble, reduceToLong etc.)

    Other miscellaneous methods (mappingCount and newKeySet) have been added as well. As a result of the JDK 8 changes, ConcurrentHashMaps (and classes built from them) are now more useful as caches. These changes include methods to compute values for keys when they are not present, plus improved support for scanning (and possibly evicting) entries, as well as better support for maps with large numbers of elements.

    a++

  11. #11
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 481
    Points : 48 794
    Points
    48 794
    Par défaut
    Tutoriel Java court mais intéressant. Par contre je m'attendais à trouver 50 points, il n'y en a que 8, un titre un peu voleur dommage

  12. #12
    Responsable Java & Kotlin

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    juillet 2005
    Messages
    14 970
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2005
    Messages : 14 970
    Points : 72 956
    Points
    72 956
    Par défaut
    @CodeZ-Julien

    Merci pour ton intervention. Je prends note et je vais modifier l'article en conséquence

    Mickael
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de Developpez.com : mbaron.developpez.com
    Twitter : www.twitter.com/mickaelbaron
    Blog : mickael-baron.fr
    LinkedIn : www.linkedin.com/in/mickaelbaron
    DBLP : dblp.uni-trier.de/pers/hd/b/Baron:Micka=euml=l

  13. #13
    Responsable Java & Kotlin

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    juillet 2005
    Messages
    14 970
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2005
    Messages : 14 970
    Points : 72 956
    Points
    72 956
    Par défaut
    Pour

    @marc.guillemin: Tu as entièrement raison, il s'agit d'une erreur d'inattention de ma part.
    Le résultat devrait afficher one, two, four.

    @ymajoros: Je suis d'accord avec toi concernant les termes manquants : Duration et ZonedDateTime.
    Etant présent sur ma version de l’article, il s'agit surement d'un oubli lors de la mise en page de celui-ci.
    C'est corrigé

    Mickael
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de Developpez.com : mbaron.developpez.com
    Twitter : www.twitter.com/mickaelbaron
    Blog : mickael-baron.fr
    LinkedIn : www.linkedin.com/in/mickaelbaron
    DBLP : dblp.uni-trier.de/pers/hd/b/Baron:Micka=euml=l

  14. #14
    Membre habitué

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    125
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2007
    Messages : 125
    Points : 173
    Points
    173
    Par défaut
    Citation Envoyé par CodeZ-Julien Voir le message
    bredelet a répondu à ta question à propos de la ConcurrentHashMap.
    Citation Envoyé par bredelet Voir le message
    Je ne sais pas si c'est nouveau, mais Oracle dit:

    http://docs.oracle.com/javase/8/docs...ntHashMap.html

    Donc il y a bien du lock-free dans ConcurrentHashMap en Java 8.
    Citation Envoyé par adiGuba Voir le message
    ConcurrentHashMap a toujours été lock-free, et ce depuis son introduction dans Java 5 : http://docs.oracle.com/javase/1.5.0/...ntHashMap.html

    Par contre elle a bien été réécrite pour Java 8, afin de profiter des améliorations apportées par les Streams et les lambdas.
    Source : http://docs.oracle.com/javase/8/docs.../changes8.html
    Globalement, les opérations de lecture ne bloquent pas et l'écriture bloque le moins possible. Ce n'est pas exactement "lock-free", et ça n'a pas été réécrit depuis Java 5.

    Pour une implémentation sans lock aucun : ConcurrentSkipListMap fait exactement ça et est là depuis un moment (1.6). Classe très intéressante, par ailleurs.

    Je lis toujours dans l'article :

    ConcurentHashMap a été complètement réécrite. Cette implémentation est thread-safe et n'utilise pas de lock.
    Je suggère de corriger ce paragraphe.

  15. #15
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par ymajoros Voir le message
    Globalement, les opérations de lecture ne bloquent pas et l'écriture bloque le moins possible. Ce n'est pas exactement "lock-free",
    On parlait bien du lock-free sur les accès en lecture ("retrieval operations do not entail locking").

    Citation Envoyé par ymajoros Voir le message
    et ça n'a pas été réécrit depuis Java 5.
    Elle a bien été réécrite dans Java 8. Il suffit de jeter un coup d'oeil au source :
    Source JDK7 : http://hg.openjdk.java.net/jdk7/jdk7...ntHashMap.java
    Source JDK8 : http://hg.openjdk.java.net/jdk8/jdk8...ntHashMap.java

    a++

  16. #16
    Membre habitué

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    125
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2007
    Messages : 125
    Points : 173
    Points
    173
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    On parlait bien du lock-free sur les accès en lecture ("retrieval operations do not entail locking").
    Moi aussi, justement. Pour revenir sur le sujet, ma réaction concerne cette partie de l'article original :

    ConcurentHashMap a été complètement réécrite. Cette implémentation est thread-safe et n'utilise pas de lock.
    Il est vrai que beaucoup semble avoir été réécrit. Par contre, qu'elle soit thread-safe est évident (ben c'est le but), et elle utilise bien des locks en écriture.

    Effectivement, en comparant les sources, je vois que beaucoup de choses ont changé.

  17. #17
    Membre habitué

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    125
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2007
    Messages : 125
    Points : 173
    Points
    173
    Par défaut
    Cette implémentation est thread-safe et n'utilise pas de lock.
    Et donc, l'article reste comme ça ?

  18. #18
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2011
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : décembre 2011
    Messages : 3
    Points : 5
    Points
    5
    Par défaut
    Bonjour ymajoros,

    Suite à tes différents échanges sur ce billet, j'ai réalisé une petite analyse de la nouvelle classe ConcurrentHashMap.
    On est tous bien d'accord qu'il n'y a pas de lock sur les opérations lecture.

    Concernant les opérations d'écriture, c'est un peu plus compliqué.
    Contrairement à la classe ConcurrentHashMap V7, l'implémentation V8 n'est plus découpée en segments (16 par défaut je crois). Ces segments impliquaient des locks sur une partie de la ConcurrentHashMap lors de l'insertion d'un élément dans un de ces segments. La déclaration de ces segments est conservée dans cette nouvelle implémentation pour des raisons de compatibilité concernant la sérialisation - voir le commentaire dans le code source
    For serialization compatibility. Null unless serialized; see below

    La nouvelle implémentation a une structure différente pour stocker les valeurs. Elles sont stockées dans une table de type Node. Un Node est composé d'un hash, de la clé, de la valeur et de l'élément suivant. Le hash correspond à une valeur calculée à partir du hashCode de la clé. Pour des raisons de performance, il est très fortement conseillé d'utiliser des objets immutables pour la clé. Ce calcul du hashCode de la clé permet d'insérer les données de manière repartie sur la table des Nodes et d'éviter au maximum les collisions entre les différentes clés.
    Dans les cas ou il y a une collision entre le calcul du hash de deux clés, les deux valeurs sont insérées dans le même Node et on en déduit que ce Node est finalement une liste chainée. Les éléments avec des hash identiques sont insérés les uns après les autres dans cette liste chainée. L'insertion du premier élément dans le Node n'utilise pas de lock et par extension de lock sur la ConcurrentHashMap. L'insertion des éléments suivants utilise un lock sur le premier élément du Node et donc il n'y a pas de lock sur les autres Node de la table. Cette explication concerne seulement l'opération put.

    Tu as raison, cette implémentation utilise des locks sur certaines opérations. La structure interne permet de réduire le nombre de locks (et son impact sur le nombre de données verrouillé) que la ConcurrentHashMap V7. Cette nouvelle implémentation offre de bien meilleur performance sur les opérations concurrentes.
    Juste une petite remarque lorsqu’il y a beaucoup trop de collisions, la table des Nodes est étendue. Je ne sais pas s’il a un lock complet sur l’ensemble des données de la ConcurrentHashMap.

    @Mickael Baron. Une petite correction de cet article est nécessaire pour lever toute ambigüité et mauvaise interprétation.

    @ymajoros. Merci pour ta contribution. J'espère que mes explications étaient assez claires.

    Julien.

  19. #19
    Membre éclairé

    Inscrit en
    juillet 2008
    Messages
    232
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 232
    Points : 837
    Points
    837
    Par défaut
    Citation Envoyé par CodeZ-Julien Voir le message
    Bonjour ymajoros,

    Suite à tes différents échanges sur ce billet, j'ai réalisé une petite analyse de la nouvelle classe ConcurrentHashMap.
    Intéressant, merci pour ton analyse. Si la clé n'est pas immuable, où perd-on du temps ?

  20. #20
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par bredelet Voir le message
    Si la clé n'est pas immuable, où perd-on du temps ?
    Ce n'est pas une raison de performance : si la clef n'est pas immuable on risque de ne plus pouvoir accéder à sa valeur.

    Les données sont stockés selon le hashCode de la clef.
    Si tu modifies la valeur de la clef après l'avoir inséré, son hashCode ne correspondra plus et tu ne pourra plus accéder à la valeur via get().

    Ce n'est pas spécifique à la ConcurrentHashMap mais commun à la majorité des Map qui ont quasi toute le même mécanisme basé sur le hashCode...


    a++

Discussions similaires

  1. C sur Linux, même chose que windows?
    Par Matthieu57b1 dans le forum Débuter
    Réponses: 25
    Dernier message: 01/02/2010, 17h39
  2. C sur mac, même chose que sur pc?
    Par Nitrox06 dans le forum Débuter
    Réponses: 4
    Dernier message: 09/05/2009, 17h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo