Google Guava vs. Apache Commons [chiuso]
-
22-07-2019 - |
Domanda
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.
Soluzione
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 predecessoreMapMaker
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.
Altri suggerimenti
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.
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.
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)
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.