D'abord, comme javamonkey79 explique, alors que Google Guava et Apache Commons partagent des caractéristiques similaires, ils ont également tous deux des fonctionnalités qui sont absentes de leur homologue. Il n'est donc pas judicieux de se limiter à une seule bibliothèque.
Cela dit, si je devais choisir, j'opterais pour Guava, en gardant Apache Commons pour les (rares) cas où Guava ne dispose pas des fonctionnalités nécessaires. Je vais essayer d'expliquer pourquoi.
La goyave est plus "moderne".
Apache Commons est une bibliothèque très mature, mais elle a aussi presque 10 ans et vise Java 1.4. Guava a été open sourced en 2007 vise Java 5, et donc Guava bénéficie grandement des fonctionnalités de Java 5 : génériques , varargs , enums y autoboxing .
Selon les développeurs de Guava, les génériques sont l'une des raisons pour lesquelles ils ont choisi de créer une nouvelle bibliothèque plutôt que d'améliorer Apache Commons (voir l FAQ google-collections sous le titre "Pourquoi Google a-t-il construit tout cela, alors qu'il aurait pu essayer d'améliorer les collections Apache Commons à la place ?". ).
Je suis d'accord avec eux : bien qu'ils soient souvent critiqués (pas de réification, limités par la rétrocompatibilité), les génériques Java sont quand même très utile lorsqu'il est utilisé de manière appropriée, comme le fait Guava. Je préférerais démissionner plutôt que de travailler avec des collections non générées !
(Notez que Apache Commons 3.0, fait cible Java 1.5+)
Guava est très bien conçu / documenté
Le code est plein de bonnes pratiques et de modèles utiles pour rendre l'API plus lisible, plus facile à découvrir, plus performante, plus sûre, plus sûre pour les fils...
Ayant lu Java efficace (livre génial d'ailleurs), je vois ces modèles partout dans le code :
- les méthodes d'usine (telles que
ImmutableList.copyOf() )
- modèle de construction (
ImmutableList.builder() , Joiner , CharMatcher , Splitter , Ordering , ...)
- immuabilité (collections immuables,
CharMatcher , Joiner , Splitter ,...)
- dissimulation de la mise en œuvre (
Predicates.xXx , ...)
- favorisant la composition par rapport à l'héritage (le
ForwardXXX collections)
- Contrôles de nullité
- modèle enum-singleton
- proxies de sérialisation
- des conventions de dénomination bien pensées
Je pourrais continuer pendant des heures à expliquer les avantages apportés par ces choix de conception (dites-moi si vous le souhaitez). Le fait est que ces modèles ne sont pas seulement "pour le spectacle", ils ont une valeur réelle : l'API est un plaisir à utiliser, plus facile à apprendre (ai-je oublié de dire combien elle est bien documentée ?), plus efficace, et de nombreuses classes sont plus simples / thread-safe en raison de leur immuabilité.
En prime, on apprend beaucoup en regardant le code :)
La goyave est cohérente
Kevin Bourrillion (le développeur principal de Guava) fait un excellent travail en maintenant un haut niveau de qualité et de cohérence dans la bibliothèque. Il n'est bien sûr pas le seul, et beaucoup d'autres personnes s'y emploient. grands développeurs ont contribué à Guava (même Joshua Bloch (qui travaille maintenant chez Google !).
Les philosophies de base et les choix de conception derrière Guava sont cohérents dans toute la bibliothèque, et les développeurs adhèrent à de très bons (IMO) principes de conception d'API, ayant appris des erreurs passées des API de JDK (pas de leur erreurs, cependant).
La goyave a un rapport poids/puissance élevé
Les concepteurs de Guava résistent à la tentation d'ajouter trop de fonctionnalités, limitant l'API aux plus utiles. Ils savent qu'il est très difficile de supprimer une fonctionnalité une fois qu'elle a été ajoutée, et suivent les principes de l'API. La devise de Joshua Bloch sur la conception des API : "En cas de doute, laissez-le de côté" . De plus, l'utilisation de l'annotation @Beta leur permet de tester certains choix de conception sans s'engager dans une API spécifique .
Les choix de conception mentionnés ci-dessus permettent d'obtenir une API très compacte. Il suffit de regarder le MapMaker pour voir la puissance que recèle un constructeur "simple". D'autres bons exemples (bien que plus simples ?) sont CharMatcher , Séparateur y Commander .
Il est également très facile de composer différentes parties de Guava. Par exemple, disons que vous voulez mettre en cache le résultat d'un processus complexe de type fonction ? Introduisez cette fonction dans votre MapMaker et BINGO, vous obtenez une carte/cache de calcul à sécurité thread. Vous avez besoin de limiter les entrées de la carte/fonction à des chaînes de caractères spécifiques ? Pas de problème, il suffit de l'intégrer dans un Carte contrainte en utilisant un CharMatcher pour rejeter les cordes inappropriées...
Guava est en développement actif
Alors que le développement d'Apache Commons semble s'être accéléré avec le travail sur Commons Lang 3.0, Guava semble prendre plus de vitesse en ce moment, tandis que Google ouvre davantage ses classes internes.
Étant donné que Google s'appuie fortement sur ce système en interne, je ne pense pas qu'il soit appelé à disparaître de sitôt. De plus, l'ouverture de ses bibliothèques communes permet à Google d'ouvrir plus facilement les sources. autre les bibliothèques qui en dépendent (au lieu de reconditionnement comme Guice actuellement fait ).
Conclusion
Pour toutes ces raisons, Guava est ma bibliothèque préférée lorsque je commence un nouveau projet. Et je suis très reconnaissant à Google et aux formidables développeurs de Guava, qui ont créé cette fantastique bibliothèque.
PS : vous pourriez également vouloir lire cette autre question sur le SO
PPS : Je ne possède pas (encore) d'actions Google.
