Google Guava vs. Apache Commons [chiuso]

212

Stavo cercando un'implementazione della mappa bidirezionale in Java, e mi sono imbattuto in queste due librerie:

Google Guava (precedentemente "Raccolte Google")
Collezioni Apache Commons

Entrambi sono gratuiti, hanno l'implementazione della mappa bidirezionale che stavo cercando (BidiMap in Apache, BiMap in Google), sono sorprendentemente quasi della stessa dimensione (Apache 493 kB, Google 499 kB) [ed .: non più vero!] E sembrano in ogni modo abbastanza simile a me.

Quale dovrei scegliere e perché? Esistono altre alternative equivalenti (devono essere gratuite e avere almeno la mappa bidirezionale)? Sto lavorando con l'ultimo Java SE, quindi non è necessario limitare artificialmente a Java 5 o cose del genere.

— Joonas Pulakka
fonte

5

Sicuramente dovresti fornirci i criteri per scegliere la biblioteca? Licenza, prestazioni, dipendenze aggiuntive, generici di supporto, ...

— SteveD

1

Google Collections è disponibile su repo1.maven.org: repo1.maven.org/maven2/com/google/collections/…

— Joachim Sauer,

Sono corretto - stavo cercando in com / googlecode

— kdgregory il

185

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

è più moderno (ha generici)
segue assolutamente i requisiti dell'API Collezioni
è attivamente mantenuto
CacheBuildered è un predecessore MapMakersemplicemente fantastico

Apache Commons Collections è anche una buona libreria, ma da tempo non è riuscita a fornire una versione abilitata ai generici (che è un grosso svantaggio per un'API di raccolte a mio parere) e generalmente sembra essere in manutenzione / non-fare -modalità troppo impegnativa La _{Commons Commons Collections ha recentemente ripreso un po 'di vapore, ma ha ancora qualcosa da recuperare.}.

Se la dimensione del download / footprint di memoria / dimensione del codice è un problema, Apache Commons Collections potrebbe essere un candidato migliore, poiché è una dipendenza comune da altre librerie. Pertanto, utilizzarlo anche nel proprio codice potrebbe potenzialmente essere fatto senza aggiungere ulteriori dipendenze. Modifica: questo particolare "vantaggio" è stato parzialmente sovvertito, poiché molte nuove biblioteche dipendono in realtà da Guava e non dalle collezioni Apache Commons.

— Joachim Sauer
fonte

3

Quello che mi chiedo davvero: perché non ci sono altre opinioni? Dovrei interpretare l'avvocato dei diavoli? Dopotutto, Apache Commons Collections non è una cattiva biblioteca.

— Joachim Sauer,

10

Dato che l'Apache manca di generici, penso sia ovvio quale di questi due sia il futuro. Google è il prossimo logico passo avanti. È una strana sensazione, tuttavia, che sia stato creato da The Giant ... ma fintanto che è sotto una licenza gratuita non dovrebbe importare anche se è stato costruito da Microsoft. Suppongo.

— Joonas Pulakka,

12

I lettori dovrebbero essere consapevoli del fatto che questa è una risposta molto vecchia e molto è cambiato

— Roy Truelove,

1

@RoyTruelove Non mi sorprende che sia cambiato molto e mi piacerebbe sentire le tue attuali opinioni in merito, o forse un link a una recensione / confronto più recente. Mi piace la filosofia "immutabile di default / mutabile solo se necessario" e l'inclusione dei generici nella guava, ma i materiali che ho letto potrebbero essere stati tutti datati come dici tu che questa discussione è diventata.

— joeA,

2

@ testerjoe2 - Mi dispiace, ho scritto quel commento molto tempo fa e sinceramente non ricordo il motivo. Col senno di poi è stato piuttosto inutile! Non mi rendevo conto che le librerie non sono cambiate dal 2010, ma so che continuano a essere usate pesantemente, e quindi direi che dovrebbero essere al sicuro. Se stavo iniziando con un nuovo progetto oggi probabilmente darei un'occhiata da vicino alla collezione lib di Goldman Sach: github.com/goldmansachs/gs-collections . Quando sei una delle aziende più malvagie del mondo, dovresti davvero assicurarti di avere una libreria di collezioni java.

— Roy Truelove,

72

Dalla domanda frequente: Domande frequenti sulle raccolte di Google

Perché Google ha creato tutto questo, quando invece avrebbe potuto provare a migliorare le collezioni Apache Commons?

Le Collezioni Apache Commons molto chiaramente non hanno soddisfatto le nostre esigenze. Non usa generici, il che è un problema per noi perché odiamo ricevere avvisi di compilazione dal nostro codice. È stato anche in un "modello di sostegno" per molto tempo. Abbiamo potuto vedere che avrebbe richiesto un investimento piuttosto importante da parte nostra per risolverlo fino a quando non fossimo felici di usarlo e, nel frattempo, la nostra biblioteca stava già crescendo organicamente.

Una differenza importante tra la nostra libreria Apache e la nostra è che le nostre collezioni rispettano fedelmente i contratti specificati dalle interfacce JDK che implementano. Se rivedi la documentazione di Apache, troverai innumerevoli esempi di violazioni. Meritano il merito di averli evidenziati in modo così chiaro, ma tuttavia, deviare dal comportamento di raccolta standard è rischioso! Devi stare attento a ciò che fai con una tale collezione; i bug aspettano sempre che accadano.

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 collezioni a qualsiasi metodo che preveda una Collezione e sentirti abbastanza sicuro che le cose funzioneranno esattamente come dovrebbero.

— Davide Consonni
fonte

71

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

Generics (Collezioni senza Generics - FTL)
Coerenza con il framework Collezioni (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 nel modo giusto.

Ecco un ottimo video di Youtube di un discorso tenuto dall'autore principale e che fa un buon lavoro nel discutere di ciò che vale la pena conoscere di questa biblioteca.

— joeslice
fonte

7

+1 per il collegamento video

— Jesper,

1

Ulteriori informazioni su Google Collections: javalobby.org/articles/google-collections (un'intervista con i suoi principali creatori). Cerca la domanda "Cosa rende unico il tuo approccio? In cosa differisce, ad esempio, dalla Collezione Apache Commons?"

— Jonik,

4

Apache Commons Collezioni Versione 4 utilizza generici. commons.apache.org/proper/commons-collections/release_4_0.html

— Abdull

-7

Altre due cose (spero di non sbagliarmi)

La licenza di Guava (nuovo nome per le raccolte google) è la licenza Apache 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 che sia possibile solo un accesso git)

— Olivier Faucheux
fonte

19

Fonti? Vuoi dire vaso che può essere attaccato in Eclipse? È qui . A proposito: cosa c'è che non va git clone https://code.google.com/p/guava-libraries/e git checkout v11.0.2?

— Xaerxess,

-7

Una cosa brutta di 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 c'è qualche buona ragione per cui è così, ma è anche scomodo.

— opaco
fonte

16

Se vuoi usare Multimaplike Map, c'è sempre asMap()vista.

— Xaerxess,

22

Come ti aspetti che una Multimap implementi java.util.Map? Una mappa multipla è sostanzialmente diversa da una mappa.

— sleske,

1

Multimap <K, V> estende Map <K, Collection <V>> .. Ho il sospetto che G avesse buone ragioni per non usare Map come superinterfaccia.

— matt

10

@lucek: Se guardi attraverso Javadoc Map, con la consapevolezza che ogni riferimento a Vsarà effettivamente un Collection<V>, penso che vedrai abbastanza rapidamente perché non è una buona superinterfaccia per Multimap<K, V>.

— Ruakh,