Google Guava vs. Apache Commons

Question

Je cherchais un carte bidirectionnelle en Java, et je suis tombé sur ces deux bibliothèques :

• Google Guava (anciennement "Google Collections")
• Collections Apache Commons

Les deux sont gratuits, ont l'implémentation de la carte bidirectionnelle que je recherchais (BidiMap dans Apache, BiMap dans Google), ont étonnamment presque la même taille (Apache 493 kB, Google 499 kB) [ndlr : ce n'est plus vrai !] et me semblent en tous points assez similaires.

Lequel dois-je choisir, et pourquoi ? Existe-t-il d'autres alternatives équivalentes (qui doivent être gratuites et avoir au moins la carte bidirectionnelle) ? Je travaille avec la dernière version de Java SE, donc pas besoin de se limiter artificiellement à Java 5 ou autre.

Answer 1

À mon avis, le meilleur choix est Goyave (anciennement connu sous le nom de Google collections) :

• il est plus moderne (il a des génériques)
• il respecte absolument les exigences de l'API Collections
• il est activement entretenu
• CacheBuilder et son prédécesseur MapMaker sont tout simplement géniaux

Apache Commons Collections est également une bonne bibliothèque, mais elle n'a pas réussi depuis longtemps à fournir une version compatible avec les génériques (ce qui est un avantage pour les utilisateurs). principal inconvénient pour une API de collecte à mon avis) et semble généralement être en mode maintenance/ne pas trop travailler dessus _{Récemment, Commons Collections a repris du poil de la bête, mais elle a du retard à rattraper.} .

Si la taille du téléchargement, l'empreinte mémoire et la taille du code sont 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, l'utiliser également dans votre propre code pourrait potentiellement être fait sans ajouter de dépendances supplémentaires. Edit : Cet "avantage" particulier a été partiellement subverti à présent, puisque de nombreuses nouvelles bibliothèques dépendent en fait de Guava et de no sur Apache Commons Collections.

Answer 2

Extrait de la FAQ : FAQ sur les collections Google

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. Elle n'utilise pas de génériques, ce qui est un problème pour nous car nous détestons obtenir des des avertissements de compilation dans notre code. Il a également été dans un "holding d'attente" depuis longtemps. Nous pouvions voir qu'il faudrait un investissement assez investissement assez important de notre part pour le réparer jusqu'à ce que nous soyons heureux de l'utiliser, et pendant ce temps, notre propre bibliothèque se développait déjà organiquement.

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 les interfaces du JDK qu'elles implémentent. Si vous consultez la vous trouverez d'innombrables exemples de violations. Ils Ils méritent d'être félicités pour les avoir signalés si clairement, mais quand même, s'écarter du comportement standard des collections est risqué ! Vous devez faire attention à ce que Vous devez faire attention à ce que vous faites avec une telle collection ; les bogues sont toujours prêts à se produire.

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

Answer 3

Les éléments les plus importants que j'ai trouvés et qui font de Google Collections l'endroit où commencer :

• Génériques (Collections sans génériques -- FTL)
• Cohérence avec le cadre des collections (Josh Bloch a joué un rôle clé dans ce cadre).
• Correct. Ces personnes sont désespérément attachées à la résolution de ce problème ; elles ont quelque chose comme 25 000 tests unitaires et sont attachées à la résolution de l'API.

Voici un grand Vidéo Youtube Il s'agit d'une conférence donnée par l'auteur principal, qui explique bien ce qu'il faut savoir sur cette bibliothèque.

Answer 4

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

• La licence de Guava (nouveau nom des collections google) est la licence Apache 2.0, c'est-à-dire la même que celle du 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).

Answer 5

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 les cartes, elles ne fonctionneront pas sur les Multimaps de Guava (l'interface Apache MultiMap étend bien java.util.Map). Je suis sûr qu'il y a une bonne raison pour laquelle il en est ainsi, mais c'est aussi un inconvénient.