Google Guava contre Apache Commons [fermé]

Question

Je recherchais une mise en œuvre de la carte bidirectionnelle en Java, et suis tombé par hasard 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 cherchais (BidiMap dans Apache, BiMap dans Google), sont étonnamment presque de la même taille (Apache 493 ko, Google 499 ko) [ed .: n'est plus vrai! ] et semblent à tous égards assez similaires à moi.

Lequel devrais-je choisir et pourquoi? Existe-t-il d'autres alternatives équivalentes (doivent être libres et avoir au moins la carte bidirectionnelle)? Je travaille avec la dernière version de Java SE, il n'est donc pas nécessaire de limiter artificiellement Java 5 ou quelque chose du genre.

Answer 1

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

• c'est plus moderne (a génériques)
• il respecte absolument les exigences de l’API Collections
• il est activement maintenu
• CacheBuilder et son prédécesseur MapMaker est tout simplement génial

Apache Commons Collections est également une bonne bibliothèque, mais elle échoue depuis longtemps à 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 un mode maintenance / peu-faire-trop-travailler-dessus _{Récemment, Commons Collections a repris de la vigueur, mais il a encore du chemin à faire pour le rattraper.} .

Si la taille de téléchargement / l'empreinte 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 courante des autres bibliothèques. Par conséquent, son utilisation dans votre propre code pourrait également être réalisée sans ajout de dépendances supplémentaires. Modifier: Cet " avantage " a été partiellement subverti à ce jour, car de nombreuses nouvelles bibliothèques dépendent en fait de Guava et pas sur Apache Commons Collections.

Answer 2

Les éléments les plus importants que j'ai trouvés et qui font de Google Collections un point de départ:

• Génériques (Collections sans génériques - FTL)
• Cadre de cohérence avec les collections (Josh Bloch était un acteur clé dans ce cadre)
• exactitude. Ces gars sont désespérément attachés à résoudre ce problème. ils ont quelque chose comme 25K tests unitaires, et sont liés à obtenir l'API juste.

Voici une excellente une vidéo Youtube d'une présentation donnée par l'auteur principal et il discute très bien de ce qu'il convient de savoir à propos de cette bibliothèque.

Answer 3

À partir de la FAQ: FAQ sur les collections Google

  

Pourquoi Google a-t-il créé tout cela alors qu'il aurait pu essayer d'améliorer les collections d'Apache Commons?

     

Les collections d’Apache Commons n’ont manifestement pas répondu à nos besoins. Il   n'utilise pas de génériques, ce qui est un problème pour nous car nous détestons nous   les avertissements de compilation de notre code. Il a également été dans un "holding"   motif " pendant longtemps. Nous pouvions voir qu'il faudrait un joli   investissement majeur de notre part pour le réparer jusqu'à ce que nous soyons heureux de l'utiliser,   et dans l'intervalle, notre propre bibliothèque grandissait 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'ils implémentent. Si vous passez en revue l'Apache   documentation, vous trouverez d'innombrables exemples de violations. Ils   méritent le crédit pour les signaler si clairement, mais toujours, déviant   du comportement de collecte standard est risqué! Vous devez faire attention à quoi   vous faites avec une telle collection; les bugs attendent toujours de 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 défini un fort   précédent pour les violations acceptables). Cela signifie que vous pouvez passer l'un des   nos collections à toute méthode qui attend une collection et se sentir   assez confiant que les choses fonctionneront exactement comme ils le devraient.

Answer 4

Deux autres choses (j'espère ne pas me tromper)

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

Answer 5

Une chose désagréable à propos de Guava est que Multimap n’étend pas java.util.Map. Si vos méthodes fonctionnent avec Google Maps, elles ne fonctionneront pas avec 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.