java - spanish - guava maven
¿Cuáles son las grandes mejoras entre las bibliotecas equivalentes de guayaba y apache? (3)
En mi experiencia, no percibo que compiten entre sí, o que la guayaba mejora las libs de apache. Más bien, la guayaba complementa las libs de apache. Hay clases y utilidades en guayaba que no están en apache y viceversa.
Por lo tanto, no sé si necesita cambiar por sí mismo, yo diría "use la herramienta adecuada para el trabajo correcto".
Actualmente utilizamos colecciones apache, string utils, etc. Necesito decidir si debemos cambiar de la implementación de fundaciones apache.
El criterio importante es la facilidad de uso de los desarrolladores. El uso de rendimiento / memoria aún no es un problema importante para nosotros. La velocidad de desarrollo es el criterio clave en este punto.
Agradecería las opiniones sobre cómo la vida del desarrollador se volvió significativamente más fácil con la guayaba.
He estado usando guayaba desde agosto de 2010, comenzando con la versión r06. Básicamente, tenía que desarrollar una biblioteca de java de nueva creación, así que busqué la mejor biblioteca adjunta para la API de J2SE. Tradicionalmente, habíamos usado las bibliotecas de Apache Commons, pero quería ver qué había y comenzar a usar Guava.
Pros
- Construcciones de lenguaje Java 5.0. La biblioteca toma la mayoría de sus claves de diseño de la "Eficaz Java: 2da Edición" de Bloch: Inmutabilidad, patrón de construcción, fábricas en lugar de constructores, genéricos, etc. Esto hace que su código sea más preciso y expresivo.
- Soporte de programación funcional, en particular con las interfaces de función y predicado de nivel superior.
Contras
- No es un reemplazo suficiente para Apache Commons, en particular commons-codec.
- No hay un ''libro de cocina de guayaba''. La biblioteca es minimalista y ortogonal. Por lo tanto, hay una curva de aprendizaje definida para aprovecharla al máximo. Como se mencionó, el Javadoc es excelente, pero algunos estudios de casos de código fuente más largos serían útiles.
- Si se encuentra en un entorno que requiere Java 1.3 o 1.4, no tiene suerte.
Para mí, Guava hace que Java se sienta más cerca de un lenguaje de scripting expresivo y escueto, y eso es genial.
Primero, como explicó javamonkey79 , mientras que Google Guava y Apache Commons comparten características similares, también tienen una funcionalidad ausente de sus contrapartes. Por lo tanto, limitarse a una sola biblioteca puede ser imprudente.
Dicho esto, si tuviera que elegir, optaría por usar guayaba, manteniendo a Apache Commons cerca para los casos (raros) donde la guayaba no tiene la funcionalidad necesaria. Déjame intentar explicar por qué.
La guayaba es más "moderna"
Apache Commons es una biblioteca realmente madura, pero también tiene casi 10 años y tiene como objetivo Java 1.4. Guava fue de origen abierto en 2007 , se dirige a Java 5 y, por lo tanto, Guava se beneficia enormemente de las características de Java 5: genéricos , varargs , enums y autoboxing .
Según los desarrolladores de Guava, los genéricos son una de las razones por la que eligieron crear una nueva biblioteca en lugar de mejorar Apache Commons (consulte las preguntas frecuentes de Google-collections , bajo el título "¿Por qué Google compiló todo esto? ¿Cuándo podría haber intentado mejorar Apache? ¿Colecciones de Commons en su lugar? " ).
Estoy de acuerdo con ellos: a pesar de que a menudo son criticados (sin reificación, limitado debido a la compatibilidad con versiones anteriores), los genéricos de Java siguen siendo muy útiles cuando se usan de forma adecuada, como hace Guava. ¡Preferiría renunciar que trabajar con colecciones no genéricas!
(Tenga en cuenta que Apache Commons 3.0, tiene como objetivo Java 1.5+)
La guayaba está muy bien diseñada / documentada
El código está lleno de prácticas recomendadas y patrones útiles para hacer que la API sea más legible, detectable, de rendimiento, segura, segura para subprocesos ...
Habiendo leído Effective Java (awesome book BTW), veo estos patrones en todas partes del código:
- métodos de fábrica (como
ImmutableList.copyOf()) - patrón de constructor (
ImmutableList.builder(),Joiner,CharMatcher,Splitter,Ordering, ...) - inmutabilidad (colecciones inmutables,
CharMatcher,Joiner,Splitter, ...) - ocultación de la implementación (
Predicates.xXx, ...) - favoreciendo la composición sobre la herencia (las colecciones de
ForwardXXX) - null-cheques
- patrón enum-singleton
- proxies de serialización
- convenciones de nombres bien pensados
Podría continuar durante horas explicando las ventajas que brindan estas opciones de diseño (dígame si lo desea). 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 documentado es?), Más eficiente y muchas clases son más simples / sin hilos debido a su inmutabilidad.
Como un punto de bonificación, uno aprende mucho mirando el código :)
La guayaba es consistente
Kevin Bourrillion (desarrollador principal de Guava) hace un gran trabajo manteniendo un alto nivel de calidad / consistencia en toda la biblioteca. Él, por supuesto, no está solo, y muchos grandes desarrolladores han contribuido a Guava (¡incluso Joshua Bloch , que ahora trabaja en Google!).
Las filosofías centrales y las elecciones de diseño detrás de Guava son consistentes en toda la biblioteca, y los desarrolladores se adhieren a muy buenos principios de diseño de API (IMO), aprendiendo de errores pasados de las API de JDK (no sus errores, sin embargo).
La guayaba tiene una alta relación potencia-peso
Los diseñadores de Guava resisten la tentación de agregar demasiadas funciones, lo que limita la API a las más útiles. Saben que es muy difícil eliminar una función una vez añadida, y siguen el lema de Joshua Bloch sobre el diseño de la API: "En caso de duda, déjalo fuera" . Además, el uso de la anotación @Beta les permite probar algunas elecciones de diseño sin comprometerse con una API específica .
Las opciones de diseño mencionadas anteriormente permiten una API muy compacta. Simplemente mira el MapMaker para ver la potencia dentro de un constructor "simple". Otros ejemplos buenos (¿más simples?) Son CharMatcher , Splitter y Ordering .
También es muy fácil componer varias partes de guayaba. Por ejemplo, supongamos que quieres almacenar en caché el resultado de una function compleja? Alimente esta función a su MapMaker y BINGO, obtendrá una caché / mapa de computación seguro para hilos. ¿Necesita restringir las entradas de mapa / función a cadenas específicas? No hay problema, envuélvalo dentro de un CharMatcher , usando un CharMatcher para rechazar cadenas inapropiadas ...
La guayaba está en desarrollo activo
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 fuentes de más de sus clases internas.
Dado que Google confía en él internamente, no creo que vaya a desaparecer pronto. Además, la apertura de sus bibliotecas comunes permite a Google abrir más fácilmente otras bibliotecas de código fuente que dependen de él (en lugar de repackaging a repackaging , como does actualmente Guice).
Conclusión
Por todos los motivos anteriores, Guava es mi biblioteca de referencia cuando empiezo 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 de SO
PPS: no tengo ninguna acción de Google (todavía)