Tout d'abord, comme l' a expliqué javamonkey79 , si Google Guava et Apache Commons partagent des fonctionnalités similaires, ils ont également tous deux des fonctionnalités absentes de leur homologue. Ainsi, se limiter à une seule bibliothèque peut être imprudent.
Cela étant dit, si je devais choisir, j'opterais pour utiliser Guava, en gardant Apache Commons dans les (rares) cas où Guava n'a pas les fonctionnalités nécessaires. Laissez-moi tenter d'expliquer pourquoi.
La goyave est plus «moderne»
Apache Commons est une bibliothèque vraiment mature, mais elle a également presque 10 ans et cible Java 1.4. Guava a été open source en 2007 , cible Java 5, et donc Guava bénéficie grandement des fonctionnalités de Java 5: génériques , varargs , enums et autoboxing .
Selon les développeurs de Guava, les génériques sont une des raisons pour lesquelles ils ont choisi de créer une nouvelle bibliothèque au lieu d'améliorer Apache Commons (voir la FAQ de google-collections , sous le titre "Pourquoi Google a-t-il construit tout cela, alors qu'il aurait pu essayer d'améliorer Apache Collections communes à la place? " ).
Je suis d'accord avec eux: bien que souvent critiqués (pas de réification, limité en raison de la rétrocompatibilité), les génériques Java sont toujours très utiles lorsqu'ils sont utilisés de manière appropriée, comme le fait Guava. Je préfère arrêter que travailler avec des collections non générées!
(Notez que Apache Commons 3.0, ne cible Java 1.5+)
La goyave est très bien conçue / documentée
Le code regorge de bonnes pratiques et de modèles utiles pour rendre l'API plus lisible, détectable, performante, sécurisée, thread-safe ...
Après avoir lu Effective Java (livre génial BTW), je vois ces modèles partout dans le code:
- méthodes d'usine (telles que
ImmutableList.copyOf())
- motif constructeur (
ImmutableList.builder(), Joiner, CharMatcher, Splitter, Ordering, ...)
- immuabilité (collections immuables,
CharMatcher, Joiner, Splitter, ...)
- mise en œuvre masquant (
Predicates.xXx, ...)
- privilégier la composition à l'héritage (les
ForwardXXXcollections)
- vérifications nulles
- modèle enum-singleton
- proxies de sérialisation
- 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 patterns ne sont pas seulement "pour le spectacle", ils ont une vraie valeur: l'API est un plaisir à utiliser, plus facile à apprendre (ai-je oublié de dire à quel point c'est bien documenté?), Plus efficace, et de nombreuses classes sont plus simples / sécurisées pour les threads en raison de leur immuabilité.
En prime, on apprend beaucoup en regardant le code :)
La goyave est cohérente
Kevin Bourrillion (développeur principal de Guava) fait un excellent travail en maintenant un haut niveau de qualité / cohérence dans toute la bibliothèque. Il n'est bien sûr pas seul, et beaucoup de 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 principes de conception d'API (IMO), ayant appris des erreurs passées des API JDK (et non de leurs erreurs, cependant).
La goyave a un rapport puissance / poids é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 ajoutée et suivent la devise de Joshua Bloch sur la conception d'API: «En cas de doute, laissez-la de côté» . En outre, 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 une API très compacte. Regardez simplement le MapMaker pour voir la puissance d'un générateur «simple». D'autres bons exemples (quoique plus simples?) Sont CharMatcher , Splitter et Ordering .
Il est également très facile de composer diverses parties de Guava. Par exemple, disons que vous souhaitez mettre en cache le résultat d'une fonction complexe ? Donnez cette fonction à votre MapMaker et BINGO, vous obtenez une carte / cache informatique thread-safe. Besoin de contraindre les entrées de mappage / fonction à des chaînes spécifiques? Pas de problème, enveloppez-le dans un ConstrainedMap , en utilisant un CharMatcher pour rejeter les chaînes inappropriées ...
La goyave 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 de l'ampleur pour le moment, tandis que Google ouvre davantage ses classes internes.
Étant donné que Google en dépend fortement en interne, je ne pense pas que cela va disparaître de si tôt. De plus, ses bibliothèques open approvisionnement commun permet à Google de sources plus facilement ouvrir d' autres bibliothèques qui en dépendent ( au lieu de reconditionner eux, comme Guice actuellement fait ).
Conclusion
Pour toutes les raisons ci-dessus, Guava est ma bibliothèque de choix lors du démarrage d'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 voudrez peut-être aussi lire cette autre question SO
PPS: Je ne possède (encore) aucune action Google