Quelles sont les grandes améliorations entre les bibliothèques équivalentes à goyave et à apache?

Nous utilisons actuellement des collections apache, des utilitaires de chaîne, etc. Je dois décider si nous devons passer de l’implémentation des fondations apache.

Le critère important est la facilité d’utilisation des développeurs. L’utilisation des performances / de la mémoire n’est pas encore un problème important pour nous. La rapidité de développement est le critère clé à ce stade.

J’apprécierais des opinions sur la façon dont la vie du développeur est devenue beaucoup plus facile avec la goyave.

Tout d’abord, comme l’ a expliqué javamonkey79 , alors que Google Guava et Apache Commons partagent des fonctionnalités similaires, ils disposent également de fonctionnalités absentes de leur homologue. Ainsi, se limiter à une seule bibliothèque peut être imprudent.

Cela étant dit, si je devais choisir, je choisirais d’utiliser Guava, en gardant Apache Commons pour 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 presque 10 ans et cible Java 1.4. Guava était une source ouverte en 2007 , cible Java 5, et Guava bénéficie donc 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 at-il essayé 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 correctement, comme le fait Guava. Je préfère quitter que de travailler avec des collections non générées!

(Notez que Apache Commons 3.0, cible Java 1.5+)

La goyave est très bien conçue / documentée

Le code est rempli de bonnes pratiques et de modèles utiles pour rendre l’API plus lisible, détectable, performante, sécurisée, sécurisée pour les threads …

Ayant lu Java efficace (livre génial BTW), je vois ces modèles partout dans le code:

  • méthodes d’usine (telles que ImmutableList.copyOf() )
  • modèle de générateur ( ImmutableList.builder() , Joiner , CharMatcher , Splitter , Ordering , …)
  • immuabilité (collections immuables, CharMatcher , Joiner , Splitter , …)
  • cache d’implémentation ( Predicates.xXx , …)
  • favoriser la composition par rapport à l’inheritance (les collections ForwardXXX )
  • null-chèques
  • motif enum-singleton
  • les proxy 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 voulez que je le fasse). 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 à quel point c’est documenté?), Plus efficace et de nombreuses classes sont plus simples / thread-safe en raison de leur immutabilité.

En bonus, 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 à travers la bibliothèque. Il n’est bien sûr pas le seul, et beaucoup de grands développeurs ont consortingbué à Guava (même Joshua Bloch , qui travaille maintenant chez Google!).

Les principes fondamentaux et les choix de conception sous-jacents à Guava sont cohérents dans toute la bibliothèque et les développeurs adhèrent aux très bons principes de conception des API (OMI), ayant appris des erreurs passées des API JDK (pas leurs erreurs).

Le goyave a un rapport poids / puissance élevé

Les concepteurs de goyave résistent à la tentation d’append 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 de suivre la devise de Joshua Bloch sur la conception de l’API: “En cas de doute, laissez tomber” . 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. Il suffit de regarder MapMaker pour voir la puissance qui règne dans un constructeur «simple». D’autres bons (mais plus simples?) Exemples sont CharMatcher , Splitter et Ordering .

Il est également très facile de composer différentes parties de Guava. Par exemple, supposons que vous souhaitiez mettre en cache le résultat d’une fonction complexe? Alimentez cette fonction sur votre MapMaker et BINGO, vous obtenez une carte / un cache informatique sécurisé. Besoin de contraindre les entrées carte / fonction à des chaînes spécifiques? Pas de problème, encapsulez-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 plus de vitesse en ce moment, tandis que Google ouvre davantage ses classes internes.

Étant donné que Google en dépend beaucoup en interne, je ne pense pas que cela va bientôt disparaître. De plus, le sourcing ouvert de ses bibliothèques communes permet à Google d’ouvrir plus facilement d’ autres bibliothèques qui en dépendent (au lieu de les reconditionner , comme le fait actuellement Guice).

Conclusion

Pour toutes les raisons ci-dessus, Guava est ma bibliothèque de référence lors du démarrage d’un nouveau projet. Et je suis très reconnaissant envers Google et les formidables développeurs de goyave qui ont créé cette fantastique bibliothèque.


PS: vous pourriez aussi vouloir lire cette autre question SO

PPS: je ne possède pas encore de stock Google

J’utilise guava depuis août 2010, à commencer par la version r06. En gros, j’avais une librairie java à développer, donc j’ai cherché la meilleure bibliothèque complémentaire pour l’API J2SE. Traditionnellement, nous utilisions les bibliothèques Apache Commons, mais je voulais voir ce qui se passait et commencer à utiliser Guava.

Avantages

  1. Constructions de langage Java 5.0. La bibliothèque utilise la plupart de ses éléments de conception dans “Effective Java: 2nd Edition” de Bloch: Immutabilité, modèle de générateur, usines au lieu de constructeurs, Génériques, etc. Cela rend votre code plus précis et plus expressif.
  2. Support de functional programming, en particulier avec les interfaces Function et Predicate de niveau supérieur.

Les inconvénients

  1. Ce n’est pas un remplacement suffisant pour Apache Commons, en particulier le codec commun.
  2. Il n’y a pas de «livre de recettes de goyave». La bibliothèque est à la fois minimaliste et orthogonale. Il y a donc une courbe d’apprentissage définie pour en tirer pleinement parti. Comme mentionné, le Javadoc est excellent, mais des études de cas plus longues de code source seraient utiles.
  3. Si vous êtes dans un environnement nécessitant Java 1.3 ou 1.4, vous n’avez pas de chance.

Pour moi, Guava rend Java plus proche d’un langage de script laconique et expressif, et c’est génial.

Dans mon expérience, je ne perçois pas qu’ils s’opposent, ou que la goyave améliore les librairies Apache. Au contraire, la goyave complète les librairies apache. Il y a des classes et des utilitaires en goyave qui ne sont pas en apache et vice versa.

Par conséquent, je ne sais pas si vous devez changer en soi – je dirais “utiliser le bon outil pour le bon travail”.