Actualmente utilizamos colecciones de apache, utilidades de cadena, etc. Necesito decidir si debemos cambiar de la implementación de las bases de apache.
El criterio importante es la facilidad de uso de los desarrolladores. El rendimiento / uso de memoria aún no es un problema importante para nosotros. La velocidad de desarrollo es el criterio clave en este punto.
Apreciaría las opiniones sobre cómo la vida del desarrollador se volvió significativamente más fácil con la guayaba.
Respuestas:
En primer lugar, como explicó javamonkey79 , aunque Google Guava y Apache Commons comparten características similares, ambos tienen una funcionalidad ausente de su contraparte. Por lo tanto, limitarse a una sola biblioteca puede ser imprudente.
Dicho esto, si tuviera que elegir, optaría por usar Guava, manteniendo Apache Commons cerca de los (raros) casos en los que Guava no tiene la funcionalidad necesaria. Déjame intentar explicar por qué.
Apache Commons es una biblioteca realmente madura, pero también tiene casi 10 años y está dirigida a Java 1.4. Guava fue de código abierto en 2007 , apunta a Java 5 y, por lo tanto , se beneficia enormemente de las características de Java 5: genéricos , varargs , enumeraciones y autoboxing .
Según los desarrolladores de Guava, los genéricos son una de las razones por las que optaron por crear una nueva biblioteca en lugar de mejorar Apache Commons (consulte las preguntas frecuentes de las colecciones de Google , bajo el título "¿Por qué Google construyó todo esto, cuando podría haber tratado de mejorar Apache? ¿Colecciones de Commons en su lugar? " ).
Estoy de acuerdo con ellos: aunque a menudo son criticados (sin reificación, limitados debido a la compatibilidad con versiones anteriores), los genéricos de Java siguen siendo muy útiles cuando se usan adecuadamente, como lo hace Guava. ¡Prefiero dejar de fumar que trabajar con colecciones no genéricas!
(Tenga en cuenta que Apache Commons 3.0, hace objetivo de Java 1.5 +)
El código está lleno de mejores prácticas y patrones útiles para hacer que la API sea más legible, reconocible, eficiente, segura, segura para subprocesos ...
Después de leer Effective Java (impresionante libro BTW), veo estos patrones en todas partes del código:
ImmutableList.copyOf())ImmutableList.builder(), Joiner, CharMatcher, Splitter, Ordering, ...)CharMatcher, Joiner, Splitter, ...)Predicates.xXx, ...)ForwardXXXcolecciones)Podría continuar durante horas explicando las ventajas que brindan estas opciones de diseño (dígame si quiere) La cuestión es que estos patrones no son solo "para el espectáculo", tienen un valor real: la API es un placer de usar, más fácil de aprender (¿olvidé decir qué tan bien documentada está?), Más eficiente y muchas clases son más simples / seguras para subprocesos debido a su inmutabilidad.
Como un punto extra, uno aprende mucho mirando el código :)
Kevin Bourrillion (desarrollador principal de Guava) hace un gran trabajo al mantener un alto nivel de calidad / consistencia en toda la biblioteca. Por supuesto, no está solo, y muchos desarrolladores excelentes han contribuido a Guava (¡incluso Joshua Bloch , que ahora trabaja en Google!).
Las filosofías centrales y las opciones de diseño detrás de Guava son consistentes en toda la biblioteca, y los desarrolladores se adhieren a los principios de diseño API muy buenos (IMO), habiendo aprendido de los errores pasados de las API JDK (sin embargo, no son sus errores).
Los diseñadores de Guava resisten la tentación de agregar demasiadas funciones, limitando la API a las más útiles. Saben que es muy difícil eliminar una característica una vez agregada, y siguen el lema de Joshua Bloch sobre el diseño de la API: "En caso de duda, no lo incluyas" . Además, el uso de la anotación @Beta les permite probar algunas opciones de diseño sin comprometerse con una API específica .
Las opciones de diseño mencionadas anteriormente permiten una API muy compacta. Simplemente mire el MapMaker para ver el poder dentro de un generador "simple". Otros buenos ejemplos (¿aunque más simples?) Son CharMatcher , Splitter y Ordering .
También es muy fácil componer varias partes de la guayaba. Por ejemplo, ¿dice que desea almacenar en caché el resultado de una función compleja ? Alimente esta función a su MapMaker y BINGO, obtendrá un mapa / caché informático seguro para subprocesos. ¿Necesita restringir las entradas del mapa / función a cadenas específicas? No hay problema, se envuelve dentro de un ConstrainedMap , utilizando un CharMatcher rechazar cadenas inapropiadas ...
Si bien el desarrollo de Apache Commons parece haberse acelerado con el trabajo en Commons Lang 3.0, Guava parece tomar más fuerza en este momento, mientras que Google abre más fuentes de sus clases internas.
Dado que Google se basa en gran medida internamente, no creo que vaya a desaparecer en el corto plazo. Además, el código abierto de sus bibliotecas comunes le permite a Google abrir más fácilmente el código fuente de otras bibliotecas que dependen de él (en lugar de volver a empaquetarlas , como lo hace actualmente Guice ).
Por todas las razones anteriores, Guava es mi biblioteca favorita cuando comienzo un nuevo proyecto. Y estoy muy agradecido con Google y con los increíbles desarrolladores de Guava, que crearon esta fantástica biblioteca.
PD: es posible que también desee leer esta otra pregunta SO
PPS: aún no tengo acciones de Google (todavía)
He estado usando guayaba desde agosto de 2010, comenzando con la versión r06. Básicamente, tenía que desarrollar una biblioteca java greenfield, así que busqué la mejor biblioteca adjunta para la API J2SE. Tradicionalmente, habíamos usado las bibliotecas de Apache Commons, pero quería ver qué había allí y comencé a usar Guava.
Para mí, Guava hace que Java se sienta más cercano a un lenguaje de scripts expresivo y conciso, y eso es genial.
En mi experiencia, no percibo que compitan entre sí, o que la guayaba mejore en las libas apache. Por el contrario, la guayaba complementa las bibliotecas apache. Hay clases y utilidades en guayaba que no están en apache y viceversa.
Por lo tanto, no sé si necesita cambiar per se: yo diría "use la herramienta adecuada para el trabajo correcto".
Files? para usar el JDK Files, tengo que escribir todo el camino ...). Mi aplicación necesitaba mucha utilidad de archivos, por lo que no pude evitar usar Apache en este caso.