Google Guava vs. Apache Commons [fermé]


212

Je cherchais une implémentation de carte bidirectionnelle en Java et suis tombé sur ces deux bibliothèques:

Les deux sont gratuits, ont l'implémentation de carte bidirectionnelle que je cherchais (BidiMap dans Apache, BiMap dans Google), sont étonnamment presque de la même taille (Apache 493 kB, Google 499 kB) [éd .: n'est plus vrai!] Et semblent à tous égards assez semblable à moi.

Lequel devrais-je choisir et pourquoi? Existe-t-il d'autres alternatives équivalentes (doivent être gratuites et avoir au moins la carte bidirectionnelle)? Je travaille avec le dernier Java SE, donc pas besoin de se limiter artificiellement à Java 5 ou quelque chose comme ça.


5
Vous devriez sûrement nous donner les critères de choix de la bibliothèque? Licence, performances, dépendances supplémentaires, prise en charge des génériques, ...
SteveD

1
Google Collections est disponible sur repo1.maven.org: repo1.maven.org/maven2/com/google/collections/…
Joachim Sauer

Je me tiens corrigé - je cherchais dans com / googlecode
kdgregory

Réponses:


185

À mon avis, le meilleur choix est la goyave (anciennement connue sous le nom de collections Google):

  • c'est plus moderne (a des génériques)
  • il suit absolument les exigences de l'API Collections
  • il est activement maintenu
  • CacheBuilderet son prédécesseur MapMakerest tout simplement génial

Apache Commons Collections est également une bonne bibliothèque, mais il a longtemps échoué à fournir une version compatible avec les génériques (ce qui est un inconvénient majeur pour une API de collections à mon avis) et semble généralement être dans une maintenance / ne pas faire -trop-beaucoup-travail-sur-it Récemment, Commons Collections a repris un peu de vapeur, mais il a du rattrapage à faire. .

Si la taille du téléchargement / l'encombrement de la mémoire / la taille du code est un problème, Apache Commons Collections pourrait être un meilleur candidat, car il s'agit d'une dépendance commune à d'autres bibliothèques. Par conséquent, son utilisation dans votre propre code pourrait également se faire sans ajouter de dépendances supplémentaires. Edit: Cet "avantage" particulier a été partiellement renversé à ce jour, car de nombreuses nouvelles bibliothèques dépendent en fait de Guava et non des collections Apache Commons.


3
Ce que je me demande vraiment: pourquoi n'y a-t-il pas d'autres opinions? Dois-je jouer l'avocat des démons? Apache Commons Collections n'est pas une mauvaise bibliothèque, après tout.
Joachim Sauer

10
Comme Apache manque de génériques, je pense qu'il est évident lequel de ces deux est le futur. Google est la prochaine étape logique vers l'avant. C'est un sentiment étrange, cependant, qu'il soit construit par The Giant ... mais tant qu'il est sous licence gratuite, cela ne devrait pas avoir d'importance, même s'il a été construit par Microsoft. J'imagine.
Joonas Pulakka

12
Les lecteurs doivent être conscients qu'il s'agit d'une réponse très ancienne et que beaucoup de choses ont changé
Roy Truelove

1
@RoyTruelove Cela ne me surprend pas que beaucoup de choses aient changé et j'aimerais entendre vos réflexions actuelles sur la question, ou peut-être un lien vers une revue / comparaison plus récente. J'aime la philosophie "immuable par défaut / modifiable uniquement si nécessaire" et l'inclusion de génériques dans la goyave, mais les documents que j'ai lus peuvent tous être datés comme vous dites que ce fil est devenu.
joeA

2
@ testerjoe2 - Désolé, j'ai écrit ce commentaire il y a longtemps et je ne me souviens vraiment pas de la raison. Rétrospectivement, c'était assez inutile! Je ne savais pas que les bibliothèques n'avaient pas changé depuis 2010, mais je sais qu'elles continuent d'être largement utilisées, et je dirais donc qu'elles devraient être en sécurité. Si je commençais avec un nouveau projet aujourd'hui, j'aurais probablement examiné de près la collection de Goldman Sach lib: github.com/goldmansachs/gs-collections . Lorsque vous êtes l'une des sociétés les plus perverses du monde, vous devez vraiment vous assurer que vous disposez d'une bibliothèque de collections java kickass.
Roy Truelove

72

De la faq: FAQ Google Collections

Pourquoi Google a-t-il construit tout cela, alors qu'il aurait pu essayer d'améliorer les collections Apache Commons à la place?

Il est clair que les collections Apache Commons ne répondaient pas à nos besoins. Il n'utilise pas de génériques, ce qui est un problème pour nous car nous détestons obtenir des avertissements de compilation de notre code. Il a également été dans un "schéma d'attente" pendant longtemps. Nous pouvions voir que cela nécessiterait un investissement assez important de notre part pour le réparer jusqu'à ce que nous soyons heureux de l'utiliser, et en attendant, notre propre bibliothèque se développait déjà de manière organique.

Une différence importante entre la bibliothèque Apache et la nôtre est que nos collections adhèrent très fidèlement aux contrats spécifiés par les interfaces JDK qu'elles implémentent. Si vous consultez la documentation Apache, vous trouverez d'innombrables exemples de violations. Ils méritent le mérite de les avoir signalés si clairement, mais tout de même, s'écarter du comportement de collecte standard est risqué! Vous devez faire attention à ce que vous faites avec une telle collection; les bogues attendent toujours de se produire.

Nos collections sont entièrement générées et ne violent jamais leurs contrats (à quelques exceptions près, où les implémentations JDK ont créé un solide précédent pour les violations acceptables). Cela signifie que vous pouvez transmettre l'une de nos collections à n'importe quelle méthode qui attend une collection et être sûr que les choses fonctionneront exactement comme elles le devraient.


71

Les choses les plus importantes que j'ai trouvées qui font de Google Collections le point de départ:

  • Génériques (Collections sans génériques - FTL)
  • Cohérence avec le cadre des collections (Josh Bloch était un acteur clé dans ce cadre)
  • Exactitude. Ces gars-là sont désespérément liés à la résolution de ce problème; ils ont quelque chose comme des tests unitaires de 25 000 et sont liés à l'obtention de l'API juste.

Voici une excellente vidéo Youtube d'une conférence donnée par l'auteur principal et il fait du bon travail pour discuter de ce qui vaut la peine d'être connu sur cette bibliothèque.


7
+1 pour le lien vidéo
Jesper

1
Grande lecture supplémentaire sur Google Collections: javalobby.org/articles/google-collections (une interview avec ses principaux créateurs). Recherchez la question "Quelle est la particularité de votre approche? En quoi diffère-t-elle, par exemple, de la collection Apache Commons?"
Jonik

4
Apache Commons Collections Version 4 utilise des génériques. commons.apache.org/proper/commons-collections/release_4_0.html
Abdull

-7

Deux autres choses (j'espère que je ne me trompe pas)

  • La licence de Guava (nouveau nom pour les collections Google) est la licence Apache 2.0, ce qui signifie: la même que pour le projet Apache Commons
  • Je ne trouve pas le code source de Guava dans un fichier à télécharger (il semble que seul un accès git soit possible)

19
Sources? Vous voulez dire un pot qui peut être attaché dans Eclipse? C'est ici . BTW: Quel est le problème avec git clone https://code.google.com/p/guava-libraries/et git checkout v11.0.2?
Xaerxess

-7

Une chose désagréable à propos de Guava est que Multimap n'étend pas java.util.Map. Si vous avez vos propres méthodes qui fonctionnent sur Maps, elles ne fonctionneront pas sur Guava Multimaps (l'interface Apache MultiMap étend java.util.Map). Je suis sûr qu'il y a une bonne raison pour laquelle c'est comme ça mais c'est aussi gênant.


16
Si vous voulez utiliser Multimapcomme Map, il y a toujours une asMap()vue.
Xaerxess

22
Comment pensez-vous qu'un Multimap implémentera java.util.Map? Une multi-carte est fondamentalement différente d'une carte.
sleske

1
Multimap <K, V> étend Map <K, Collection <V>> .. Je soupçonne cependant que G avait de bonnes raisons de ne pas utiliser Map comme superinterface.
mat

10
@lucek: Si vous regardez dans le Javadoc Map, sachant que chaque référence Vsera en fait un Collection<V>, je pense que vous verrez assez rapidement pourquoi ce n'est pas une bonne superinterface Multimap<K, V>.
ruakh
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.