Muchas veces pienso que lo complicado no es elegir un software para realizar un proyecto que tienes en mente, o simplemente pasar un rato, analizando lo que se cocina en el mundo a nivel de programación.

Cuándo quieres ver paquetes realizados por grupos de software libre, o simplemente analizar lo que están haciendo la comunidad de programadores, más expertos que uno mismo, te das cuenta que hay diferentes paquetes para una misma solución, y cada uno de ellos con sus pros y contra.

Por ejemplo si deseas realizar una api para imprimir documentos en PDF, tienes el paquete itext, pero dicha solución, que anteriormente era código abierto, ha evolucionado de licencia LGPL a AGPL, por supuesto hay muchos más como PDFBox.

Si deseas conectar con una Base de Datos con un conector puro de JAVA, se tenía el conector mysql, pero al ser comprado por Oracle, pasamos a conectores como Maria.

Si deseamos exportar datos directamente a formatos offices, tenemos el paquete poi, pero si evolucionas a las últimas versiones, te das cuenta que los enlaces que has realizado, muchos de ellos petan, porque han cambiado la clase o el método, o simplemente dicen que la clase está en desuso, y si tienes documentación del cambio, perfecto, pero generalmente en muchos paquetes tienes que tirar de otras personas, que antes han pasado por el mismo problema. Si deseas realizar una exportación e importación en Json, aquí tienes hasta 5 paquetes diferentes, y si te equivocas en elegir el adecuado, el rendimiento de la aplicación y del ordenador se verá penalizado en tiempos de respuesta.

Si eliges paquetes que a su vez estos eligen otros paquetes para poder funcionar, puedes tener duplicado lo mismo, pero en paquetes diferentes, hasta más de dos veces, por ejemplo paquetes como Oshi que necesita en algunos casos un paquete en concreto de Json, o paquetes como hibernate o quatz que necesitan entre otros el log4J.

Una vez que eliges un paquete en concreto, intentas pasarlo por los controles estándar de verificación, como el Sonar y analizar la versión que gran parte del código ha sido programado, y tengo que indicar que muchos de los paquetes más populares de java, tienen errores de estructura que no veas, no pasan por las 405 reglas del Sonar ni por asomo, y aveces eso me tira para atrás a la hora de analizar y ver la estructura de programación de dicho paquete realizado en java.

Sin contar con los problemas que uno puede tener en el propio código de programación al subir de versión de Java, de la 1.4 a 1.6 a 1.8 a …………….. Con tantas variables diferentes, pienso que no solo es la programación sino que es necesario una bola de cristal para saber el futuro más próximo para cometer los menos errores posibles ………..