Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

50 nouvelles choses que l'on peut faire avec Java 8,
Retour de la conférence Devoxx France 2014 par Julien Sadaoui

Le , par Mickael Baron

0PARTAGES

2  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de benratti
Membre confirmé https://www.developpez.com
Le 27/08/2014 à 11:33
la session est disponible sur parleys, comme toutes les sessions de devoxx france 2014
1  0 
Avatar de marc.guillemin
Membre à l'essai https://www.developpez.com
Le 16/09/2014 à 10:07
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,
1  0 
Avatar de CodeZ-Julien
Futur Membre du Club https://www.developpez.com
Le 02/10/2014 à 8:41
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 : Sélectionner tout
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.
1  0 
Avatar de wax78
Modérateur https://www.developpez.com
Le 03/09/2014 à 14:15
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).
0  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 03/09/2014 à 15:55
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++
0  0 
Avatar de ymajoros
Membre habitué https://www.developpez.com
Le 17/09/2014 à 9:50
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
0  0 
Avatar de Mickael Baron
Responsable Java https://www.developpez.com
Le 17/09/2014 à 10:19
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
0  0 
Avatar de bredelet
Membre éclairé https://www.developpez.com
Le 17/09/2014 à 23:53
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.
0  0 
Avatar de CodeZ-Julien
Futur Membre du Club https://www.developpez.com
Le 18/09/2014 à 23:22
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,
0  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 19/09/2014 à 8:42
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++
0  0