Apache Commons vs. Guava (precedentemente “Google Collections”)

Stavo cercando un’implementazione cartografica bidirezionale in Java e sono incappato in queste due librerie:

  • Collezioni Apache Commons
  • Guava (precedentemente “Google Collections”)

Entrambi sono gratuiti, l’implementazione della mappa bidirezionale che stavo cercando (BidiMap in Apache, BiMap in Google), ha all’incirca la stessa dimensione (Apache 493 kB, Google 499 kB) [ed .: non è più vero!] E sembra in tutti i modi molto simile a me.

Quale dovrei scegliere e perché? Ci sono altre alternative equivalenti (devono essere gratuite e avere almeno la mappa bidirezionale)? Sto lavorando con l’ultima versione di Java SE, quindi non è necessario limitare artificialmente a Java 5 o qualcosa del genere.

Secondo me la scelta migliore è Guava (precedentemente noto come raccolte Google):

  • è più moderno (ha generici)
  • segue assolutamente i requisiti dell’API delle collezioni
  • è mantenuto triggersmente
  • CacheBuilder e il suo predecessore MapMaker sono semplicemente fantastici

Apache Commons Collections è anche una buona libreria, ma da tempo non è riuscita a fornire una versione abilitata per i generici (che a mio parere è un grosso svantaggio per un’API di collezioni) e in genere sembra essere in una manutenzione / non fare -troppo-molto-lavoro-su-it di recente Le Collezioni di Commons hanno ripreso un po ‘di vapore, ma ha un po’ di recupero. .

Se la dimensione del download / ingombro della memoria / dimensione del codice è un problema, allora Apache Commons Collections potrebbe essere un candidato migliore, poiché è una dipendenza comune di altre librerie. Pertanto, utilizzarlo nel proprio codice potrebbe potenzialmente essere eseguito senza aggiungere ulteriori dipendenze. Modifica: Questo particolare “vantaggio” è stato parzialmente sovvertito, poiché molte nuove librerie dipendono effettivamente da Guava e non da Apache Commons Collections.

Le cose più importanti che ho trovato rendono Google Collections il punto di partenza:

  • Generics (Collections without Generics – FTL)
  • Coerenza con il framework Collections (Josh Bloch è stato un attore chiave in questo framework)
  • Correttezza. Questi ragazzi sono disperatamente legati a risolvere questo problema; hanno qualcosa come 25K unit test, e sono legati per ottenere l’API giusto.

Ecco un grande video di Youtube di un discorso che è stato dato dall’autore principale e fa un buon lavoro nel discutere di cosa valga la pena conoscere su questa libreria.

Da faq: domande frequenti su Google Collections

Perché Google ha costruito tutto questo, quando invece avrebbe potuto provare a migliorare le raccolte di Apache Commons?

Le collezioni Apache Commons molto chiaramente non hanno soddisfatto i nostri bisogni. Non usa i generici, che è un problema per noi perché odiamo ricevere avvisi di compilazione dal nostro codice. È stato anche in un “modello di partecipazione” per lungo tempo. Potremmo vedere che richiederebbe un grosso investimento da parte nostra per sistemarlo fino a quando non saremmo stati felici di usarlo e, nel frattempo, la nostra biblioteca stava già crescendo in modo organico.

Una differenza importante tra la libreria Apache e la nostra è che le nostre collezioni aderiscono in modo molto fedele ai contratti specificati dalle interfacce JDK che implementano. Se rivedi la documentazione di Apache, troverai innumerevoli esempi di violazioni. Meritano il merito di averlo indicato in modo così chiaro, ma comunque, deviare dal comportamento di raccolta standard è rischioso! Devi stare attento a ciò che fai con una tale collezione; gli errori stanno aspettando sempre per accadere.

Le nostre collezioni sono completamente generate e non violano mai i loro contratti (con eccezioni isolate, in cui le implementazioni di JDK hanno creato un forte precedente per violazioni accettabili). Ciò significa che puoi passare una delle nostre raccolte a qualsiasi metodo che si aspetta una Collezione e sentirti abbastanza sicuro che le cose funzioneranno esattamente come dovrebbero.

Una cosa brutta su Guava è che Multimap non estende java.util.Map. Se hai i tuoi metodi che funzionano su Maps, non funzioneranno su Guava Multimaps (l’interfaccia Apache MultiMap estende java.util.Map). Sono sicuro che ci sia una buona ragione per cui è così com’è, ma è anche scomodo.

Altre due cose (spero di non sbagliarmi)

  • La licenza di Guava (nuovo nome per le raccolte google) è la Apache License 2.0, che significa: la stessa del progetto Apache Commons
  • Non riesco a trovare il codice sorgente di Guava in un file da scaricare (sembra solo un accesso git è ansible)