Discussion :

[Mickael Baron]

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

[benratti]

la session est disponible sur parleys, comme toutes les sessions de devoxx france 2014

[wax78]

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

[adiGuba]

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

[marc.guillemin]

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,

[ymajoros]

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

[Mickael Baron]

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

[bredelet]

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

[Invité]

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,

[adiGuba]

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

[tchize_]

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

[Mickael Baron]

@CodeZ-Julien

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

Mickael

[Mickael Baron]

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

[ymajoros]

bredelet a répondu à ta question à propos de la ConcurrentHashMap.

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

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.

[adiGuba]

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

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

[ymajoros]

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

[ymajoros]

Cette implémentation est thread-safe et n'utilise pas de lock.

Et donc, l'article reste comme ça ?

[Invité]

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.

[bredelet]

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 ?

[adiGuba]

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