Je cherchais une implémentation de carte bidirectionnelle en Java et suis tombé sur ces deux bibliothèques:
Les deux sont libres, 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 semblable à 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 le dernier Java SE, il n'est donc pas nécessaire de limiter artificiellement à Java 5 ou quoi que ce soit du genre.
À mon avis, le meilleur choix est Guava (anciennement connu sous le nom de Google Collections):
CacheBuilder
et son prédécesseur MapMaker
sont tout simplement géniauxApache 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 à mon avis = majeur pour une API de collections) et semble généralement être en mode maintenance/travail-pas-beaucoup-beaucoup-de-travail Récemment, Commons Collections a repris Steam, mais il a encore du chemin à faire..
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 commune à d'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. Edit: Cet "avantage" particulier a été partiellement partiellement renversé, car de nombreuses nouvelles bibliothèques dépendent en fait de Guava et pas d'Apache Commons Collections.
Les éléments les plus importants que j'ai trouvés et qui font de Google Collections un point de départ:
Voici un excellent vidéo Youtube d'une conférence donnée par l'auteur principal et il discute très bien de ce qu'il convient de savoir à propos de cette bibliothèque.
De la FAQ: FAQ Google Collections
Pourquoi Google at-il créé tout cela alors qu’il aurait pu essayer d’améliorer les collections d’Apache Commons?
Les collections 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 obtenir des avertissements de compilation à partir de notre code. Il a également été dans un "schéma de maintien" pendant une longue période. 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 entre-temps, notre propre bibliothèque avait déjà une croissance organique.
Une différence importante entre la bibliothèque Apache et la nôtre réside dans le fait 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 découvrirez d'innombrables exemples de violations. Ils méritent d'être félicités pour les avoir signalés si clairement, mais néanmoins, s'écarter du comportement de collecte standard présente des risques! Vous devez faire attention à ce que 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 (à quelques exceptions près, où les implémentations de JDK ont créé un précédent solide en matière de violations acceptables). Cela signifie que vous pouvez transmettre l'une de nos collections à n'importe quelle méthode qui attend une collection et avoir la certitude que les choses fonctionneront exactement comme elles le devraient.