Google Guava vs. Apache Commons [chiuso]

Question

Stavo cercando una mappa bidirezionale in Java e mi sono imbattuto in queste due librerie:

• Google Guava (precedentemente " Collezioni Google ")
• Collezioni di 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 qualche modo abbastanza simili 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 c'è bisogno di limitarsi artificialmente a Java 5 o cose del genere.

Answer 1

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

• è più moderno (ha generici)
• segue assolutamente i requisiti dell'API Collezioni
• è attivamente gestito
• CacheBuilder ed è il suo predecessore MapMaker sono semplicemente fantastici

Apache Commons Collections è anche una buona libreria, ma a lungo non è riuscita a fornire una versione abilitata ai generici (che è un grave svantaggio per un'API delle raccolte a mio parere) e generalmente sembra essere in modalità manutenzione / non-fare-troppo-lavoro-su-it _{Recentemente la Commons Commons ha ripreso un po 'di vapore, ma ha un po' di recupero da fare.} .

Se la dimensione del download / footprint di memoria / dimensione del codice è un problema, allora le collezioni Apache Commons potrebbero 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" ormai è stato parzialmente sovvertito, dal momento che molte nuove librerie dipendono in realtà da Guava e non dalle collezioni Apache Commons.

Answer 2

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

• Generics (Collezioni senza Generics - FTL)
• Coerenza con il framework delle raccolte (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 fantastico video di Youtube di un discorso tenuto dall'autore principale e fa un buon lavoro nel discutere ciò che vale la pena sapere di questa biblioteca.

Answer 3

Dalla domanda frequente: Domande frequenti sulle raccolte di Google

  

Perché Google ha creato tutto questo, quando invece avrebbe potuto tentare di migliorare le raccolte Apache Commons?

     

Le collezioni Apache Commons molto chiaramente non hanno soddisfatto le nostre esigenze. esso   non usa i generici, il che è un problema per noi che odiamo ottenere   avvisi di compilazione dal nostro codice. È stato anche in una partecipazione "   Reticolo " per molto tempo. Abbiamo potuto vedere che avrebbe richiesto una bella   importanti investimenti da parte nostra per risolverlo fino a quando non saremo felici di usarlo,   e nel frattempo la nostra biblioteca stava già crescendo organicamente.

     

Una differenza importante tra la libreria Apache e la nostra è quella   le nostre collezioni rispettano fedelmente i contratti indicati da   le interfacce JDK che implementano. Se rivedi Apache   documentazione, troverai innumerevoli esempi di violazioni. Essi   meritano il merito di averlo sottolineato così chiaramente, ma comunque, deviando   dal comportamento di raccolta standard è rischioso! Devi stare attento a cosa   lo fai con una tale raccolta; i bug sono sempre in attesa di accadere.

     

Le nostre collezioni sono completamente generate e non violano mai i loro contratti   (con eccezioni isolate, in cui le implementazioni di JDK hanno fissato un punto di forza   precedente per violazioni accettabili). Questo significa che puoi superarne uno   le nostre collezioni a qualsiasi metodo che preveda una collezione e una sensazione   abbastanza fiducioso che le cose funzioneranno esattamente come dovrebbero.

Answer 4

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)

Answer 5

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