Análisis de las librerías usadas por los 10,000 proyectos Java más populares de GitHub
AbrahamEn este enlace han hecho un análisis de las librerías usadas por los 10,000 proyectos Java más populares de GitHub, empleando para ello el archivo pom.xml de estos proyectos. El propósito es tratar de ver que librerías son más usadas dentro de la plataforma Java. Y este es el resultado:
Slf4j y jUnit son los reyes indiscutibles, con más de un 30% de uso de entre estos proyectos. Siguen varias librerías de logging, la librería de commons de Apache y Guava de Google. En el artículo original también se trata de extraer una serie de conclusiones sobre algunas tecnologías que están bastante de moda en la actualidad, como NoSQL, Hadoop y Android.
¿Qué os parecen estos resultados? ¿Concuerdan estas estadísticas con vuestra percepción de qué librerías son más populares dentro de las aplicaciones Java?
Reader Comments (8)
Poco me parece para el Framework Spring, que sólo un 3.8 de los proyectos lo tengan.
mucho me parece Spring tenga tanto
un framework tan difícil de configurar y de curva de aprendizaje tan alta
no todos los proyectos son aplicaciones web completas de las que te pagan por hacer
Pues desde mi punto de vista sea o no sea una web completa creo que la inyección de dependencias es lo más útil que tiene ya sea para un web o para una aplicación de escritorio puede aplicarse perfectamente. Yo ya no sé vivir sin inyección de dependencias, al igual que sin SVN o Git.
Seguramente no es tu caso, antuansoft, pero sospecho que la mayoría de la gente confunde el concepto de "inyección de dependencias" con "inyección AUTOMÁTICA/ASISTIDA de dependencias"...
Los frameworks de inyección de dependencias son una contradicción en si mismos, el principal motivo para usar DI es depender de abstracciones en lugar de depender de implementaciones concretas, el problema es que si usas un framework para hacer esta labor te vuelves casi con toda seguridad dependiente de ese mismo framework. Coger un app spring y cualquiera y intentar quitar sprint y cambiarlo que se yo por guice.
No veo la necesidad de usar cosas esotéricas como ficheros de configuración xml o anotaciones para hacer lo mismo que se puede hacer con el operador "new" y un buen diseño.
Por cierto, en github una gran parte de los proyectos que encontrareis no son aplicaciones sino más bien frameworks y librerías, lo normal si haces una librería es condicionar lo menos posible a los usuarios de esa librería, por eso es logico que el porcentaje de uso de spring sea tan bajo teniendo en cuenta la tipología de proyectos de github. Si estas haciendo, que se yo, una librería de mocks (como mockito) no vas a usar spring para obligar a los usuarios de mockito a arrastrar la dependencia de spring.
Buen apunte jmarranz.
Inyeccion de dependencias se lleva haciendo toda la vida porque alli donde habia un interface o un virtual, terminaba habiendo una inyeccion de dependencias. Lo que pasa es que se hacia con un setter (aunque no se llamara asi) o un new, y como era lo nomral y nadie vendia libros sobre algo que era lo normal no se hablaba de ello.
Lo importante de Spring no es la inyeccion de dependencias, si no los aspectos, que es una manera diferente de diseñar las aplicaciones. Igual que de estructurada a POO hay un cambio en el diseño de las aplicaciones y son cosas diferentes, de POO a AoP hay otro salto. Y tengo la sensacion de que se usa Spring pero no se usa AoP mas alla de sacar algun log o comprobar alguna credencial.
Hola Luis,
en parte tienes razón , Spring tiene una curva de aprendizaje al alta, pero ello es debido a que Spring es muy amplio, tiene ya demasiadas cosas.
Yo en mi caso solo quiero la parte de Inyección de Dependencias y usar los controladores en apps web.
Pues bien, una vez que has quitado toda la paja de la documentación. Te das cuenta que configurarlo simplemente es:
* Crear un "applicationContext.xml" que prácticamente solo tiene las FQCN de mis clases que implementan interfaces.
* Crear un "dispatcher-servlet.xml" que solo cambia el nombre del paquete donde están mis controladores
* Modificar el "web.xml" para añadir un servlet y un listener (siempre es el mismo código excepto por una expresión regular).
Y ya puedo usar Spring con "@Autowired" ,"@Controller" "@RequestMapping" ,"@PathVariable" , etc.
¿Cuanto he tardado en configurarlo? No más de 5 min.
¿Cuanto ha costado en prender?: No más de 3 o 4 horas en aprender las anotaciones mas útiles.
Yo en clase lo cuento en 6 horas y lo entienden de sobra.
Coincido en todas las letras con logongas, no obstante, para desarrollo empresarial, vale la pena invertir tiempo en recorrer la curva de aprendizaje, una vez hecho esto las soluciones salen como churros.