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

Retour de la conférence Devoxx France 2014 par Julien Sadaoui

Le 2014-08-26 09:35:25, par Mickael Baron, Rédacteur

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

Discussion forum

21 commentaires

benratti
Membre confirmé

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

le 27/08/2014 à 11:33
marc.guillemin
Membre à l'essai

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,

le 16/09/2014 à 10:07

Bonjour bredelet,

adiGuba décrit très bien le problème avec les objets mutables. Je t’encourage très fortement à ne jamais utiliser ce type d’objet comme clé. Ça va forcément générer des bugs dans tes applications. Il a raison sur ce point, pas besoin de parler de performances pour ces objets.

Il a quelques considérations à prendre en compte quand tu utilises des objets immuables sur les performances.

L’intérêt de la table de hachage est d’accéder de manière quasi immédiate à une valeur à partir de sa clé. Les implémentations de Map sont basées comme cités ci-dessus sur un mécanisme basé sur le hash code de la clé. Le calcul du hash code est coûteux dans ces structures de données, elle passe leur temps à calculer des hash code. Pour cette raison, il est primordial d’utiliser des objets immuables dont le calcul du hash code est rapide.
Certaines classes du JDK sont de bonnes candidates pour être des clés :

Integer : le hash code de l’entier est l’entier lui-même
String : le hash code est réalisé sur un calcul de chaque caractère de la chaîne (coûteux). Le hash code est mis en cache lors du premier calcul de celui-ci.

Ci-dessous le code source de la méthode hashCode() de String.
La variable d’instance "hash" permet la mise en cache de ce hash code.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public int hashCode() { 
        int h = hash; 
        if (h == 0 && value.length > 0) { 
            char val[] = value; 
 
            for (int i = 0; i < value.length; i++) { 
                h = 31 * h + val[i]; 
            } 
            hash = h; 
        } 
        return h; 
    }

Les objets immuables ne changent pas avec le temps, on a seulement besoin de calculer une seule fois ce hash code. Il est primordial de stocker ce hash code en cache quand l’objet est utilisé comme clé d’un HashMap ou ConcurrentHashMap, surtout lorsque celui-ci est très coûteux à calculer. Ne pas mettre en cache le hash code des clés va forcément entrainer des non-performances dans l’utilisation de votre table de hachage. Les dégradations des performances seront de plus en plus importantes au fur et à mesure de la taille et de l’utilisation de la table.

Utilisez de préférences des classes telles que Integer ou String comme clé. Si vous utilisez des objets immuables, pensez à bien mettre en cache le hash lors du premier calcul.

Julien.

le 02/10/2014 à 8:41

wax78
Modérateur

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

le 03/09/2014 à 14:15
adiGuba
Expert éminent sénior

Envoyé par wax78

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

le 03/09/2014 à 15:55
ymajoros
Membre habitué

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

le 17/09/2014 à 9:50
Mickael Baron
Rédacteur

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

le 17/09/2014 à 10:19
bredelet
Membre éclairé

Envoyé par ymajoros

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

le 17/09/2014 à 23:53
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,

le 18/09/2014 à 23:22
adiGuba
Expert éminent sénior

Envoyé par bredelet

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

le 19/09/2014 à 8:42

Poster une réponse