Un par de cosillas/problemillas que me he encontrado sobre las dependencias de unos jar con otros.
Maven por un lado
Supón que tenemos un proyecto A con maven que tiene a su vez dos subproyectos B y C. Si le decimos a maven a través de los ficheros pom.xml que B necesita de C para compilar y que C necesita de B para compilar, maven, obviamente, protesta. La excusa es que no sabe qué debe compilar primero, ya que el uno depende del otro. Hasta aquí todo parece correcto.
Supongamos ahora la misma estructura de proyectos de antes, pero esta vez decimos que B necesita a C para compilar y que C necesita de B sólo en tiempo de ejecución (runtime). Pues bien, maven protesta igualmente. Sin embargo, esta vez, la excusa ya no vale. Si B necesita de C para compilar y C sólo necesita a B en runtime, entonces está claro que se puede compilar primero C y luego B. Esto ya es algo que puede en un momento dado molestar, aunque quizás no sea muy correcto un proyecto con esta dependencia.
Pero ahora viene lo peor. Si en vez de un proyecto A con subproyectos B y C tenemos directamente dos proyectos maven independientes, B y C, maven teóricamente sería capaz de detectar igualmente las dependencias. En el repositorio de jars que usemos estarán los jar de B y C y sus ficheros pom.xml con las dependencias. Sin embargo, al ser independientes, NO protesta. En principio no podemos llegar a esta situación directamente, ya que si B necesita de C para compilar y C necesita de B para compilar, no podemos compilar ninguno de los dos, ya que en ningún caso estará el jar del otro en el repositorio (ya que no hemos podido compilarlo). Pero sí podemos hacerlo poco a poco, en unos proyectos reales que evolucionan con el tiempo. Podemos empezar creando los proyectos B y C como indpendientes e ir compilándolos. Según avanzan los proyectos, en un momento dado podemos necesitar la dependencia de B con C y la añadimos. Todo bien. Pero según avanzamos más y por descuido, podemos añadir la dependencia de C con B…. y maven no protesta, puesto que encuentra los jar anteriores en el repositorio y no revisa las dependencias entre proyectos independientes.
Usar muchas librerías, por otro lado
Este otro problema es más filosófico que de una herramienta concreta, aunque me he tropezado con él en la realidad. Supón que haces un proyecto java y decides usar librerías de terceros, de esas libres que hay por ahí, por ejemplo, jasperreport, jfreechart, ibatis, hibernate, etc. Digamos, por ejemplo, que decides usar la A y la B. Pues bien, es bastante fácil que ambas necesiten de alguna librería más de terceros, por ejemplo, log4j. Por generalizar, tanto A como B necesitan que nos descarguemos e incluyamos en nuestro proyecto a C. Sin problemas de momento.
Pero, ¿qué pasa si A necesita C-1.0 y B necesita C-2.0 y las versiones 1.0 y 2.0 son incompatibles?. Pues básicamente que la hemos cagado. Para que todo vaya bien, necesitamos las dos versiones de la librería y tendremos problemas a la hora de configurar el classpath, porque muchas clases estarán repetidas en ambas versiones y se encontrará la primera que pongamos en el classpath, que puede ser la que no le gusta a la librería A y que de paso le sienta mal a la B. Y si ponemos sólo una, A no funciona y si ponemos sólo la otra, es B el que protesta.
Desgraciadamente, estas situaciones van siendo cada vez más comunes. Hay librerías java como las apache-commons, log4j, etc que son muy, pero que muy utilizadas por muchísimas librerías de más alto nivel, como hibernate, jfreechart, etc. Todas estas librerías de alto nivel no avanzan a la vez ni se actualizan con la misma frecuencia, por lo que puede ser normal que una necesite log4j-1.2.13 y otra log4j-1.2.15. Con log4j en concreto no hay mucho problema, pero sí hay otras más conflictivas.
A cuento con lo de elegancia o sencillez, este parece un motivo para ir más a la sencillez que a la elegancia. Las liberías de alto nivel que pretendan ser compatibles con otras librerías de alto nivel que no tienen nada que ver ellas, deberían casi casi reinventar la rueda cada vez en vez de usar librerías de más bajo nivel. O quizás estas librerías de muy bajo nivel y mayoritariamente usadas deberían venir prácticamente incluidas en el JDK de java.
No se, veo difícil solución y preveo que a la larga la cosa ira empeorando. De momento es difícil tropezarse con estas situaciones, pero a mí ya me ha ocurrido alguna vez.
Lo que comenta esta bien, lo poco que endiento es que PreparedStatement precompila la sentencia SQL, y en ocasiones no se conocen los parametros, po ejemplo para dar de al a un cliente desde un formulario, de momento no se conoce al cliente pero se puede crear un objeto preparedStatement y una vez que se tengan los datos se ejecuta la sentencia pasando los datos como parametros, ahi creo que si se ve el rendimiento, voy a ser algunas pruebas haber que pasa,