Apache Commons vs Guava (anciennement “Google Collections”)

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

  • Collections Apache Commons
  • Goyave (anciennement “Google Collections”)

Les deux sont gratuits, la mise en œuvre de la carte bidirectionnelle que je cherchais (BidiMap dans Apache, BiMap dans Google) est étonnamment proche de la même taille (Apache 493 Ko, Google 499 Ko). de toute façon très similaire à moi.

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

À mon avis, le meilleur choix est Guava (anciennement connu 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
  • CacheBuilder et son prédécesseur MapMaker sont tout simplement géniaux

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 une maintenance / ne pas faire. -too-much-work-on-it-mode Recent Commons Collections a repris de la vigueur, mais il y a du rattrapage à faire. .

Si la taille du fichier à télécharger / l’empreinte mémoire / la taille du code pose 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 être effectuée sans append de dépendances supplémentaires. Edit: Cet “avantage” particulier a été partiellement renversé maintenant, car de nombreuses nouvelles bibliothèques dépendent en fait de Guava et non d’Apache Commons Collections.

Les choses les plus importantes que j’ai trouvées 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 é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 25K et sont liés à l’obtention de l’API juste.

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

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?

Les collections Apache Commons ne répondaient manifestement pas à nos besoins. Il n’utilise pas de génériques, ce qui est un problème pour nous car nous détestons recevoir des avertissements de compilation de notre code. Il a également été dans un “schéma de maintien” pendant longtemps. Nous avons pu constater que cela exigerait un investissement important de notre part pour que nous puissions l’utiliser, et en attendant, notre propre bibliothèque était déjà en pleine croissance.

Une différence importante entre la bibliothèque Apache et la nôtre est que nos collections respectent très fidèlement les contrats spécifiés par les interfaces JDK qu’elles implémentent. Si vous examinez la documentation Apache, vous trouverez d’innombrables exemples de violations. Ils méritent d’être récompensés pour les avoir clairement signalés, mais s’écarter du comportement de collecte standard est risqué! Vous devez faire attention à ce que vous faites avec une telle collection; les bugs ne font que survenir.

Nos collections sont entièrement généralisées et ne violent jamais leurs contrats (avec des exceptions isolées, où les implémentations JDK ont créé un précédent solide 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 que vous êtes certain que tout fonctionnera comme prévu.

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 Google Maps, elles ne fonctionneront pas sur les multimodes Gava (l’interface Apache MultiMap étend java.util.Map). Je suis sûr qu’il y a de bonnes raisons pour que ce soit comme ça, mais c’est aussi gênant.

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: le même que pour le projet Apache Commons
  • Je ne parviens pas à trouver le code source de Guava dans un fichier à télécharger (il semble que seul un access git soit possible)