Google Guava vs. Apache Commons [cerrado]

Question

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

• Google Guava (anteriormente " Google Collections ")
• Colecciones de 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 me parecen bastante parecidos a todos.

¿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.

Answer 1

En mi opinión, la mejor opción es Guava (anteriormente conocido como Google colecciones):

• es más moderno (tiene genéricos)
• sigue absolutamente los requisitos de la API de colecciones
• se mantiene activamente
• CacheBuilder y su predecesor MapMaker son simplemente impresionantes

Apache Commons Collections también es una buena biblioteca, pero durante mucho tiempo no ha podido proporcionar una versión habilitada para genéricos (que es un inconveniente major para una API de colecciones en mi opinión) y en general parece estar en un modo de mantenimiento / no hacer demasiado trabajo en él _{Recientemente, 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 particular "ventaja" ahora se ha subvertido parcialmente, ya que muchas bibliotecas nuevas realmente dependen de Guava y no de las colecciones de Apache Commons.

Answer 2

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)
• Corrección. Estos muchachos están desesperadamente atados a solucionar este problema; tienen algo así como pruebas unitarias de 25K y están vinculados a obtener la API correcta.

Aquí hay un excelente video de Youtube de una charla dada por el autor principal y hace un buen trabajo discutiendo lo que vale la pena saber sobre esta biblioteca.

Answer 3

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 en su lugar?

     

Las colecciones de Apache Commons claramente no satisfacían nuestras necesidades. Eso   no usa genéricos, lo cual es un problema para nosotros ya que odiamos tener   advertencias de compilación de nuestro código. También ha estado en un " holding   patrón " por mucho tiempo. Pudimos ver que requeriría una bonita   una gran inversión de nuestra parte para arreglarlo hasta que estemos 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 revisas el Apache   documentación, encontrará innumerables ejemplos de violaciones. Ellos   Merecen crédito por señalar esto tan claramente, pero aún así, desviarse   ¡El comportamiento de recolección estándar es arriesgado! Debes tener cuidado con lo que   lo haces con tal colección; los errores siempre están esperando que sucedan.

     

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

Answer 4

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)

Answer 5

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.