Discussion :

[thierryler]

Les Collections Java ont un peu plus d'une douzaine d'années d'existence et s'imposent comme une des plus importantes APIs du monde Java. De nombreux framework en utilisent les fonctionnalités et les étendent. C'est notamment le cas de Google-Collections qui ajoute des évolutions intéressantes comme les Prédicats, les objets Multi ou Bi, les immutables, etc. Ce document est un point de départ à la découverte des éléments clés de Google-Collections.

Que pensez-vous de cet article ?

Article : http://thierry-leriche-dessirier.dev...e-collections/

[gailuris]

Salut,

Merci pour la découverte de cette API que je ne connaissais pas (je vais l'étudier de plus près et peut-être l’intégrer à mes prochain projets).

J'ai trouvé de petite coquilles : les sources ne sont pas disponibles (cela dit les exemples sont suffisamment simples pour que ce ne soit pas un problème), et dans la partie sur les précondition le code

Code :

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

this.age = checkArgument(0 <= age, "Un age ne peut pas être négatif");

ne peut pas fonctionner puisque checkArgument ne renvoi rien.

[deltree]

Bonjour,
c'est un article intéressant, j'ai appris quelque chose, et je pense que je vais m'en servir.
ça rappelle très largement les jakarta-commons colllection pour les convertisseur et prédicate, mais c'est en Java 5 contrairement aux commons (ce qui m'a un poil ennuyé sur mon projet actuel).

petites critiques de formes (c'est tout ce qui reste quand le fond est ok ):

- "VIII. Functionnal-collections": un seul n
- "On pourrait croire que ImmutableMap.of() est une eliypse mais pas du tout." : je n'ai pas compris. (ça existe eliypse ?)
- "Vector" : on n'a pas dit qu'on utilisai ArrayList maintenant? Vector ça fait très Java 1.1.x

[thierryler]

@gailuris : j'avais oublié de le corriger en effet. Merci de me l'avoir signalé.

@deltree : J'ai utilisé les arraylists dans tout le reste de l'article alors je voulais varier un peu, histoire de dire que ça ne se limite pas aux arrays.

[Tommy31]

A noter que google-collections est maintenant un sous-ensemble du projet guava (http://code.google.com/p/guava-libraries/).

[thierryler]

@Tommy31 : Effectivement c'est ce que je me suis contenté de dire dans l'article car je souhaitais me concentrer sur les collections et ce qui gravite autour. Guava est très intéressant aussi, mais G-Collections est le "module" le plus important. Toutefois je prévoie de compléter l'article d'ici quelques temps (et/ou de faire un article à part) avec un chapitre sur guava.

[dingoth]

Bonjour,

Très bon article dans l'ensemble qui couvre un bon gros 50% de la bibliothèque, mais 90% des besoins des utilisateurs finaux.

Cependant j'ai plusieurs remarques :
* Vu l'actualité galopante de Guava, je crois qu'il est bien mieux de réellement parler de Guava dans tout l'article plutôt que de google-collections, dans lequel déjà plusieurs bugs ont été trouvés mais fixés seulement dans Guava.
* Pourquoi parler de Vector ? Si Vector a été "oublié" dans <s>google-collection</s> guava, c'est pour une raison particulière. Vector ne doit plus être utilisé du tout. Pour arriver à un Vector, il suffit de faire ceci :

Code :

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

1
2
List<String> unsynchronizedList = ...;
List<String> synchronizedList = Collections.synchronizedList(unsynchronized);

* Pourquoi dire que le HashMultiset trie les résultats ? C'est faux... Utilisez un jeu de donnée plus important et vous verrez : les résultats ne sont pas triés. Le tri est un hasard lié au hashcode et à l'implémentation. Exécutez ceci pour preuve :

Code :

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

1
2
3
4
5
6
List<Integer> l = Lists.newArrayList();
for (int i = 1; i <= 1000; i++) {
	l.add(i);
}
Multiset<Integer> x = HashMultiset.create(l);
System.out.println(x);

* Le terme français pour "ordonneur" est "ordonnateur" ;
* Dans l'exemple sur le joiner, pourquoi compliquer la vie de l'utilisateur avec des StringBuilder ? Je ne crois pas qu'il y a de "cas précis" dans ce cas : c'est tout simplement le cas général. Le code suivant fait exactement la même chose et est plus court :

Code :

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

1
2
3
4
5
return Joiner.on(SEPARATEUR).join(transform(personnes, new Function<Personne,String>(){
  @Override public String apply (Personne p) {
    return p.getPrenom() + " " + p.getNom();
  }
}));

* Enfin et c'est très mineur, vous avez écrit "static private Ordering creerAgeOrdering() {" au lieu de "static private Ordering<Personne> creerAgeOrdering() {"

À noter également la "fraternité" entre Guava et Glazed List. Tout ce qui manque dans Guava se trouve généralement dans le projet Glazed List : les développeurs de Guava ne veulent pas faire doublon avec Glazed List.

[thierryler]

@dingoth Très bonnes remarques.

Pour le Vector, je pense que c'est une bonne part de souvenir de mes débuts en Java... J'ai du mal à lâcher mon premier amour ;-) Je trouve ton exemple de liste non synchro qui devient synchro très intéressant. C'est une technique que je n'ai pas l'habitude d'utiliser mais j'en vois directement tous les avantages par rapport à utiliser un vector (synchro) dès l'affectation. En tous cas, je viens de remplacer les vectors par des arraylists pour vous faire plaisir ;-)



Pour le HashMultiSet, effectivement je me suis emballé un peu là : je ne sais pas ce qui m'a pris lol. Surtout que je disais bien le contraire juste au dessus :

Les MultiSets représentent la réponse de Google-Collections à un manque de Java concernant les Sets. En effet, les Sets, en Java, sont des listes non ordonnées qui ne contiennent pas de doublon. Ce qui est important ici, c'est que ce soit non ordonné et sans doublon. Java propose aussi les Lists qui sont ordonnées et peuvent contenir des doublons. Mais il n'y a aucune solution pour des listes non ordonnées avec doublon, et c'est justement ce à quoi correspondent les MultiSets. Avec un multiset, il est possible d'ajouter plusieurs fois la même valeur, sans forcément que l'ajout soit ordonné.

Pour le joiner, en fait, je voulais mettre un exemple non trivial, qui justifie d'utiliser un joiner un peu complexe au lieux de passer directement par le jdk, mais je ne trouve pas d'exemple parlant (sans en faire des pages et des pages)

Bon bon, ok ok je vais parler de guava et de glazed dans la prochaine version.

[Yo Eight]

Merci pour cet article.

Cependant, j'ai du mal à voir le plus apporté comparé aux common-collections d' Apache ?

[Tommy31]

Le plein support des generics !

[dingoth]

Guava est également :
* 100% compliant avec l'api Collections de Java (parfois apache-commons prend des libertés).
* en développement là où commons colletions semble être uniquement en maintenance

Moi, ça me suffit

[eclesia]

Jolie article mais ...

J'ai deja rencontré la pluspart de ses collections dans plusieurs projets tels que apache-commons, jersey, geotk/geoapi ... il n'y a pas grand merite si ce n'est le nom qui en fait de la publicité a lui seul.

Ce n'est pour la plupart que du sucre syntaxique plutot dangereux pour les non-avertis, particulierement l'ecriture newYYY qui me semble un tres mauvais choix.

Il manque aussi beaucoup de choses, comme les sequences, CacheMap, DisjointSet, CodeList, FrequencySortedSet, RangeSet, NotifiedList ... etc ...
C'est encore loin d'etre complet. la majorité de ce que je viens de citer est dans le projet GeotoolKit avec une 40ene de classes utilitaire sur les collections qui remonte pour certaines a pres de 8ans ... et pourtant ce n'est pas son objectif.

De la a dire que cette librairie offre quelque chose de nouveau ... faut arreter, c'est une Nième compilation de code deja bien réchauffé

Ne vous jetez pas sur tout ce qui a le nom g....

ps : on ecrit "public static" et non "static public"

[thierryler]

@eclesia : Effectivement il existe d'autres frameworks qui proposent sensiblement la même chose, parfois mieux, parfois pire... Pour le coup, cet article ne présente pas ces frameworks mais Google-Collections, qui répond à la "plupart" des problèmes courants.

Il est vrai que si on utilise déjà un des frameworks cités, le passage à Google-Collections est moins intéressant.

Dans une prochaine version de l'article, je prévoie d'ajouter un chapitre pour comparer Google-Collections avec les autres frameworks, notamment commons-collections et ceux que tu cites.

[dingoth]

Ce n'est pour la plupart que du sucre syntaxique plutot dangereux pour les non-avertis, particulierement l'ecriture newYYY qui me semble un tres mauvais choix.

Peux-tu élaborer ? Parce qu'une syntaxe similaire à celle-ci est prévue pour Java 7 (la syntaxe "diamond").

Ce n'est nullement dangereux comme code. Cela respecte parfaitement les bonnes pratiques standard de Java (voir le livre Effective Java, par exemple) afin de pallier au problème des constructeurs.

Edit: Guava connait CacheMap (voir MapMaker), DisjointSet (MapDiff), FrequencySortedSet (Ordering+ Multiset implementation), et les autres, je les connais pas, donc j'en parle pas.

Enfin, le nom Guava a été choisi pour remplacer google-collections afin de justement ne pas faire jouer le nom G.....

Bref, j'ai l'impression que tu as un a-priori assez fort contre la bibliothèque s'en t'être penché dessus un minimum.

[thierryler]

Et d'ailleurs j'en parle dans l'article : On notera que l'idée des déclarations simplifiée avait déjà été proposée par Josh Bloch dans son livre "Effective Java 2" et devrait arriver dans Java 7 (ou 8)

[eclesia]

Peux-tu élaborer ? Parce qu'une syntaxe similaire à celle-ci est prévue pour Java 7 (la syntaxe "diamond").

La syntaxe diamond c'est different quand meme :

Code :

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

1
2
3
4
5
 
//diamond
ArrayList<String> lst = new ArrayList<>()
//gc
ArrayList<String> lst = newArrayList()

je trouve que la seconde prete a confusion, un appelle a une methode n'est pas la meme chose qu'un constructeur.

Ce n'est nullement dangereux comme code. Cela respecte parfaitement les bonnes pratiques standard de Java (voir le livre Effective Java, par exemple) afin de pallier au problème des constructeurs.

Je ne remet pas en cause les constructeurs static, un terme plus approprié comme celui utilisé dans les factory serait plus judicieux : createArrayList()

Edit: Guava connait CacheMap (voir MapMaker), DisjointSet (MapDiff), FrequencySortedSet (Ordering+ Multiset implementation), et les autres, je les connais pas, donc j'en parle pas.

Juste pour expliquer les quelques autres :
- sequence : une classe proxy qui itere sur plusieurs collections a la fois, succesive sur chaque collection qu'elle encapsule.
- codelist : l'equivalent d'un enum a taille variable, ca a été créé dans le cas des normes ISO/OGC qui definissent des valeurs possibles que certain profils etendent avec de nouvelles valeurs.
- FrequencySortedSet : un set qui ordonne ses elements selon leur frequence, plus on fait de add d'un element plus il remonte dans l'ordre.
- RangeSet : une collection d'interval, de date a date, nombre a nombre qui se fusionne automatiquement.
- NotifiedList : liste concurrente qui envoit des evenements lors d'ajout, suppression ... utile dans le cas ou l'on travail avec des listes vivantes.

Enfin, le nom Guava a été choisi pour remplacer google-collections afin de justement ne pas faire jouer le nom G.....

ca ressemble plus a une remarque en l'air sans plus de détail, je ne peux m'empecher de penser au projet Guice en entendant Guava. a croire qu'ils vont breveter les noms de projets en G.... (j'exagere bien sur, enfin j'espere)

Bref, j'ai l'impression que tu as un a-priori assez fort contre la bibliothèque s'en t'être penché dessus un minimum.

Effectivement, je n'ai fait que parcourir rapidement les classes presentent dans la javadoc et uniquement le package collect.
D'ailleur je remarque qu'ils ont dupliqué aussi le travail fait dans JSR-275 Unit, et on fait leur propre systeme d'unité réduite au minimum.

Pour répondre a ta question tres honnetement : oui je n'aime pas G... pour avoir saccagé a deux reprises mon domaine de travail (la cartographie),
- avec une specification imposé de force a l'OGC (le fameux format KML)
- une incompétence avérée pour avoir créé une définition de projection (en gros une formule permettant de calculer la position d'un point sur la planete vers un point sur un plan) et n'etre meme pas capable de l'appliquer correctement dans ses logiciels. Comme bien sur tout le monde se jete aveuglement sur les outils G... l'erreur est partout désormais et c'est trop tard pour la rectifier (ont ilsmeme essayé) donc on a une exception sur quelques milliers de projection qu'il faudra prendre en compte a chaque fois.

Ajouter a cela que cette société a tendance a dupliquer tout ce qui lui plait, a ne pas se priver pour nous traquer et se faire de l'argent en vendant nos petites habitudes.

Je mettais G.. au meme niveau que Sun en terme d'innovation et d'ouverture, mais c'etait avant de decouvrir les bassesses de cette société. Autant avec Microsoft / Apple / Oracle les intentions sont clairs, autant avec G... c'est de la mesquinerie.

Se sont des développeurs comme les autres, leurs projets ne sont pas mieux non plus.

[thierryler]

Petite màj : ajout du builder pour les ConcurrentMap

[thierryler]

Màj : Ajout du pattern Converter de Spring à combiner avec Lists.transform()

[thierryler]

Màj : Ajout de la syntaxe Diamons à titre indicatif.

[thierryler]

màj : la méthode "transform()" fonctionne un peu comme un proxy. C'est hyper important à savoir pour ne pas avoir de mauvaise surprise. La transformation donne une vue qui n'est réellement convertie que sur besoin.

http://thierry-leriche-dessirier.dev...ections/#LIV-C