Google Guava vs. Apache Commons [cerrado]

212

Estaba buscando una implementación de mapa bidireccional en Java, y me topé con estas dos bibliotecas:

Google Guava (anteriormente "Colecciones de Google")
Colecciones Apache Commons

Ambos son gratuitos, tienen la implementación del mapa bidireccional que estaba buscando (BidiMap en Apache, BiMap en Google), son increíblemente casi del mismo tamaño (Apache 493 kB, Google 499 kB) [ed .: ¡ya no es cierto!] Y parecen en todos los sentidos bastante similar a mí.

¿Cuál debo elegir y por qué? ¿Existen otras alternativas equivalentes (deben ser gratuitas y tener al menos el mapa bidireccional)? Estoy trabajando con el último Java SE, por lo que no es necesario limitar artificialmente a Java 5 ni nada por el estilo.

— Joonas Pulakka
fuente

55

¿Seguramente deberías darnos los criterios para elegir la biblioteca? De licencia, funcionamiento, dependencias adicionales, el apoyo a los genéricos, ...

— SteveD

1

Google Collections está disponible en repo1.maven.org: repo1.maven.org/maven2/com/google/collections/…

— Joachim Sauer

Estoy corregido - Estaba buscando en com /

— googlecode

185

En mi opinión, la mejor opción es la guayaba (anteriormente conocida como colecciones de Google):

Es más moderno (tiene genéricos)
sigue absolutamente los requisitos de la API de colecciones
se mantiene activamente
CacheBuildery su predecesor MapMakeres simplemente increíble

Apache Commons Collections también es una buena biblioteca, pero durante mucho tiempo no ha podido proporcionar una versión genérica habilitada (que es un gran inconveniente para una API de colecciones en mi opinión) y, en general, parece estar en mantenimiento / no hacer -todo-mucho-trabajo-en-modo _{Recientemente, Commons Commons Collections ha recogido algo de fuerza nuevamente, pero tiene que ponerse al día.}.

Si el tamaño de descarga / huella de memoria / tamaño de código es un problema, entonces Apache Commons Collections podría ser un mejor candidato, ya que es una dependencia común de otras bibliotecas. Por lo tanto, usarlo en su propio código también podría hacerse sin agregar ninguna dependencia adicional. Editar: esta "ventaja" en particular se ha subvertido parcialmente ahora, ya que muchas bibliotecas nuevas realmente dependen de Guava y no de las colecciones de Apache Commons.

— Joachim Sauer
fuente

3

Lo que realmente me pregunto: ¿por qué no hay otras opiniones? ¿Debería estar jugando al abogado de los demonios? Apache Commons Collections no es una mala biblioteca, después de todo.

— Joachim Sauer

10

Como el Apache carece de genéricos, creo que es obvio cuál de estos dos es el futuro. Google es el siguiente paso lógico hacia adelante. Sin embargo, es una sensación extraña que esté construido por The Giant ... pero siempre que esté bajo una licencia gratuita, no debería importar incluso si fue construido por Microsoft. Supongo.

— Joonas Pulakka

12

Los lectores deben tener en cuenta que esta es una respuesta muy antigua y que muchas cosas han cambiado

— Roy Truelove

1

@RoyTruelove No me sorprende que haya cambiado mucho y me encantaría escuchar sus opiniones actuales sobre el tema, o tal vez un enlace a una revisión / comparación más reciente. Me gusta la filosofía "inmutable por defecto / mutable solo si es necesario" y la inclusión de genéricos en la guayaba, pero los materiales que he estado leyendo pueden haber sido fechados como usted dice que este hilo se ha convertido.

— joeA

2

@ testerjoe2 - Lo siento, escribí ese comentario hace mucho tiempo y, francamente, no recuerdo el motivo. En retrospectiva, ¡fue bastante inútil! No me di cuenta de que las bibliotecas no han cambiado desde 2010, pero sí sé que continúan siendo muy utilizadas, por lo que diría que deberían ser seguras. Si comenzara hoy con un nuevo proyecto, probablemente miraría de cerca la colección lib de Goldman Sach: github.com/goldmansachs/gs-collections . Cuando eres una de las compañías más malvadas del mundo, realmente debes asegurarte de tener una biblioteca de colecciones java increíble.

— Roy Truelove

72

De las preguntas frecuentes : Preguntas frecuentes sobre las colecciones de Google

¿Por qué Google construyó todo esto, cuando podría haber intentado mejorar las Colecciones de Apache Commons?

Las Colecciones de Apache Commons claramente no satisfacían nuestras necesidades. No utiliza genéricos, lo cual es un problema para nosotros ya que odiamos recibir advertencias de compilación de nuestro código. También ha estado en un "patrón de espera" durante mucho tiempo. Pudimos ver que requeriría una inversión bastante grande de nuestra parte para arreglarlo hasta que estuviéramos felices de usarlo, y mientras tanto, nuestra propia biblioteca ya estaba creciendo orgánicamente.

Una diferencia importante entre la biblioteca Apache y la nuestra es que nuestras colecciones se adhieren muy fielmente a los contratos especificados por las interfaces JDK que implementan. Si revisa la documentación de Apache, encontrará innumerables ejemplos de violaciones. Se merecen el crédito por señalarlos con tanta claridad, pero aun así, ¡desviarse del comportamiento de cobranza estándar es arriesgado! Debes tener cuidado con lo que haces con tal colección; los errores siempre están esperando a suceder.

Nuestras colecciones están completamente generadas y nunca violan sus contratos (con excepciones aisladas, donde las implementaciones de JDK han establecido un fuerte precedente para violaciones aceptables). Esto significa que puede pasar una de nuestras colecciones a cualquier método que espere una Colección y sentirse bastante seguro de que las cosas funcionarán exactamente como deberían.

— Davide Consonni
fuente

71

Las cosas más importantes que he encontrado que hacen de Google Collections el lugar para comenzar:

Genéricos (Colecciones sin genéricos - FTL)
Consistencia con el marco de Colecciones (Josh Bloch fue un jugador clave en este marco)
Exactitud. Estos muchachos están desesperadamente atados a solucionar este problema; tienen algo así como 25K pruebas unitarias, y están vinculados a obtener la API correcta.

Aquí hay un gran video de YouTube de una charla dada por el autor principal y él hace un buen trabajo al discutir lo que vale la pena saber sobre esta biblioteca.

— joeslice
fuente

77

+1 para el enlace del video

— Jesper

1

Gran lectura adicional sobre Google Collections: javalobby.org/articles/google-collections (una entrevista con sus principales creadores). Busque la pregunta "¿Qué tiene de especial su enfoque? ¿En qué se diferencia, por ejemplo, de la Colección Apache Commons?"

— Jonik

44

La versión 4 de Apache Commons Collections usa genéricos. commons.apache.org/proper/commons-collections/release_4_0.html

— Abdull

-7

Otras dos cosas (espero no estar equivocado)

La licencia de Guava (nuevo nombre para las colecciones de google) es la Licencia Apache 2.0, que significa: la misma que para el proyecto Apache Commons
No puedo encontrar el código fuente de Guava en un archivo para descargar (parece que solo es posible un acceso git)

— Olivier Faucheux
fuente

19

¿Fuentes? ¿Te refieres a jar que se puede adjuntar en Eclipse? Es aquí . Por cierto: ¿Qué hay de malo con git clone https://code.google.com/p/guava-libraries/y git checkout v11.0.2?

— Xaerxess 05 de

-7

Una cosa desagradable sobre Guava es que Multimap no extiende java.util.Map. Si tiene sus propios métodos que funcionan en Maps, no funcionarán en Guava Multimaps (la interfaz Apache MultiMap sí extiende java.util.Map). Estoy seguro de que hay una buena razón por la cual es así, pero también es inconveniente.

— mate
fuente

16

Si quieres usar Multimaplike Map, siempre hay asMap()vista.

— Xaerxess

22

¿Cómo espera que un Multimap implemente java.util.Map? Un mapa múltiple es fundamentalmente diferente de un mapa.

— sleske

1

Multimap <K, V> extiende Map <K, Collection <V>> ... Aunque sospecho que G tenía buenas razones para no usar Map como superinterfaz.

— mate

10

@lucek: Si busca en el Javadoc Map, con el entendimiento de que cada referencia Vserá realmente Collection<V>, creo que verá muy rápidamente por qué no es una buena superinterfaz Multimap<K, V>.

— ruakh