Attualmente usiamo collezioni apache, utilità di stringa, ecc. Devo decidere se dobbiamo passare dall'implementazione delle basi di apache.
Il criterio importante è la facilità d'uso degli sviluppatori. Le prestazioni / l'utilizzo della memoria non sono ancora un problema importante per noi. La velocità di sviluppo è il criterio chiave a questo punto.
Apprezzerei le opinioni su come la vita dello sviluppatore sia diventata significativamente più facile con guava.
Risposte:
Prima di tutto, come ha spiegato javamonkey79 , mentre Google Guava e Apache Commons condividono funzionalità simili, entrambi hanno funzionalità assenti dalla loro controparte. Pertanto, limitarsi a una sola libreria potrebbe non essere saggio.
Detto questo, se dovessi scegliere, sceglierei di usare Guava, mantenendo Apache Commons in giro per i (rari) casi in cui Guava non ha le funzionalità necessarie. Vorrei provare a spiegare perché.
Apache Commons è una libreria molto matura, ma ha anche quasi 10 anni e si rivolge a Java 1.4. Guava è stato open source nel 2007 , si rivolge a Java 5 e quindi Guava beneficia notevolmente delle funzionalità di Java 5: generics , varargs , enums e autoboxing .
Secondo gli sviluppatori di Guava, i generici sono una delle ragioni per cui hanno scelto di creare una nuova libreria invece di migliorare Apache Commons (vedi le FAQ di google-collections , sotto il titolo "Perché Google ha creato tutto questo, quando avrebbe potuto provare a migliorare Apache Commons Collections invece? " ).
Sono d'accordo con loro: sebbene spesso criticati (nessuna reificazione, limitati a causa della retrocompatibilità), i generici Java sono ancora molto utili se usati in modo appropriato, come fa Guava. Preferisco smettere di lavorare con raccolte non generate!
(Si noti che Apache Commons 3.0, fa bersaglio Java 1.5+)
Il codice è pieno di best practice e pattern utili per rendere l'API più leggibile, rilevabile, performante, sicura, thread-safe ...
Dopo aver letto Effective Java (fantastico libro BTW), vedo questi modelli ovunque nel codice:
ImmutableList.copyOf())ImmutableList.builder(), Joiner, CharMatcher, Splitter, Ordering, ...)CharMatcher, Joiner, Splitter, ...)Predicates.xXx, ...)ForwardXXXcollezioni)Potrei andare avanti per ore a spiegare i vantaggi portati da queste scelte progettuali (dimmi se vuoi che lo faccia). Il fatto è che questi pattern non sono solo "per lo spettacolo", hanno un valore reale: l'API è un piacere da usare, più facile da imparare (mi sono dimenticato di dire quanto è ben documentata?), Più efficiente e molte classi sono più semplici / thread-safe a causa della loro immutabilità.
Come punto bonus, si impara molto guardando il codice :)
Kevin Bourrillion (lo sviluppatore principale di Guava) fa un ottimo lavoro mantenendo un alto livello di qualità / coerenza in tutta la libreria. Ovviamente non è solo, e molti grandi sviluppatori hanno contribuito a Guava (anche Joshua Bloch , che ora lavora per Google!).
Le filosofie di base e le scelte di progettazione alla base di Guava sono coerenti in tutta la libreria e gli sviluppatori aderiscono a principi di progettazione API (IMO) molto buoni, avendo imparato dagli errori passati delle API JDK (non dai loro errori, però).
I designer Guava resistono alla tentazione di aggiungere troppe funzionalità, limitando le API a quelle più utili. Sanno che è molto difficile rimuovere una funzionalità una volta aggiunta e seguono il motto di Joshua Bloch sulla progettazione delle API: "In caso di dubbio, lasciarla fuori" . Inoltre, l'utilizzo dell'annotazione @Beta consente loro di testare alcune scelte di progettazione senza impegnarsi in un'API specifica .
Le scelte progettuali sopra menzionate consentono un'API molto compatta. Basta guardare il MapMaker per vedere la potenza racchiusa in un "semplice" builder. Altri buoni esempi (anche se più semplici?) Sono CharMatcher , Splitter e Ordering .
È anche molto facile comporre varie parti di Guava. Ad esempio, supponi di voler memorizzare nella cache il risultato di una funzione complessa ? Fornisci questa funzione al tuo MapMaker e BINGO, hai una mappa / cache di elaborazione thread-safe. Hai bisogno di vincolare gli input della mappa / funzione a stringhe specifiche? Nessun problema, avvolgilo all'interno di una ConstrainedMap , usando un CharMatcher per rifiutare le stringhe inappropriate ...
Mentre lo sviluppo di Apache Commons sembra aver accelerato con il lavoro su Commons Lang 3.0, Guava sembra prendere più vapore al momento, mentre Google apre più fonti delle loro classi interne.
Poiché Google fa molto affidamento su di esso internamente, non credo che scomparirà presto. Inoltre, l'open source delle sue librerie comuni consente a Google di aprire più facilmente altre librerie che dipendono da esso (invece di riconfezionarle , come fa attualmente Guice ).
Per tutti i motivi di cui sopra, Guava è la mia libreria di riferimento quando si avvia un nuovo progetto. E sono molto grato a Google e ai fantastici sviluppatori Guava, che hanno creato questa fantastica libreria.
PS: potresti leggere anche quest'altra domanda SO
PPS: Non possiedo (ancora) azioni Google
Uso guava dall'agosto 2010, a partire dalla versione r06. Fondamentalmente, avevo una libreria java greenfield da sviluppare, quindi ho cercato la migliore libreria aggiuntiva per l'API J2SE. Tradizionalmente, usavamo le librerie Apache Commons, ma volevo vedere cosa c'era là fuori e ho iniziato a usare Guava.
Per me, Guava fa sentire Java più vicino a un linguaggio di scripting conciso ed espressivo, e questo è fantastico.
Nella mia esperienza non percepisco che si contendono l'un l'altro, o che la guava migliora sulle librerie di apache. Piuttosto, guava completa le librerie di apache. Ci sono classi e utilità in guava che non sono in apache e viceversa.
Pertanto, non so se devi cambiare di per sé - direi "usa lo strumento giusto per il lavoro giusto".
Files? Ora ogni volta che voglio per usare il JDK Files, devo scrivere l'intero percorso ...). La mia app necessitava di molta utilità File, quindi in questo caso non ho potuto evitare di utilizzare Apache.