Anti – JSP: Y II

Esta entrada es la continuación de la entrada Anti – JSP

Después de haber superado el primer inconveniente, es decir que las paginas no se veían en Firefox 3, vino el segundo, las tablas no funcionaban, algo que me parecía raro, pero que a final de cuentas no me extraño para nada, recordemos que se trata de JSP, y sin tener mucho conocimiento, me dispuse a ver como resolver ese detalle, cosa que me llevo alrededor de una semana, llena de frustraciones y un estado de aborrecimiento cada vez mayor hacía el culpable de mis males es decir JSP.

Al fin, cuando logre resolver el problema, si bien de la forma más elegante, pero si funcional o al menos hacía lo que yo quería que hiciera, y eso me basto para empezar a avanzar en mi caso de uso, que por cierto una vez que agarre ritmo termine lo más rápido posible, por varias razones, pero la principal es que estaba harto del JSP y sus malditos frameworks, de los cuales no hay mucha información al respecto, es decir que en el mejor de los casos te podrían ahorrar mucho tiempo de programación con sus componentes, desafortunadamente no hay casi nada de documentación con respecto a esos frameworks y como me menciono mi jefe, es el precio que hay que pagar por usar lo más nuevo en lo que a JSP se refiere.

¿Alguna vez han utilizado una computadora que pareciera estar en cámara lenta, que cada cosa que quisieran hacer dependiera del humor de está?, pues si algún día tienen que usar el NetBeans 6.1 y usan GlassFish  juntos,  podrán decir que si, y es que una Giga de RAM no es suficiente para que estas bestias devoradoras de memoria puedan trabajar de forma fluida, y sin trabar la computadora, no se diga si tienes música o usas el Messenger o tienes abierto algún documento en MS Word,como en mi caso para ver el caso de uso,  porque prácticamente los Deploys (incluyendo la compilada) serán de 1 minuto o hasta 4 en algunos de los peores casos, es decir que si modificas algo, por pequeño que sea tendrás que esperar a que tu código sea compilado y luego sea llevado a la carpeta del servidor GlassFish, es decir el tal deploy.

De nada sirve un framework lleno de objetos a los que no les puedes modificar su comportamiento, es decir que si el componente no se comporta como tu lo necesitas, pues tiene mucho por que hacer, ya que los objetos que ves en el navegador ( botones, campos de texto y la gran mayoría de ellos), no son los botones estándar, es decir son componentes creados con javascript, que no en todos los casos se comportan como los de los navegadores y por lo tanto si quieres hacer algo en javascript vas a batallar un rato más para encontrar como se comportan dichos objetos.

Hay que decir que el problema de NetBeans es de raíz, es decir JAVA nunca ha sido muy bueno manejando la memoria, si activamos el medidor de memoria de NetBeans veremos como sin hacer absolutamente nada en la IDE, sin tocar el ratón o el teclado, NetBeans comienza a comer memoria, tal vez no en cantidades enormes es decir no de mega en mega, pero si en decimos de estos, y dirán que tanto es tantito pero el detalle es que no se esta haciendo nada, por lo tanto no debería de haber gasto extra de memoria, haciendo una analogía,diríamos que si apagamos el motor de auto y este empezara a gastar el Gasolina, esto no sería normal y en la mayoría de los casos lo atribuiríamos a fugas en alguna de las conexiones en el sistema de combustible o a  otro tipo de daños. Así pues NetBeans y JAVA sobre todo, son unos grandes glotones de memoria, memoria que no puedes administrar, ya que una de las principales características de java es que no administras  la memoria directamente, es decir JAVA la administra por ti.

Entronces en resumen que hemos aprendido en estas dos entradas, bueno pues que JSP apesta, que el framework de la WebUI es bueno mientras no necesites nada especial, que GlassFish en consume muchisima memoria, de repente cercas de 1GB solo para soportar un simple servidor, y que si no estas dispuesto a lidiar con poca documentación y no quieres complicarte a existencia con algo que requiere muchos recursos (no todos podemos invertir en un servidor Sun Con tecnología Sparc corriendo a 64bits)  utiliza algo más ligero, tanto en entornos de desarrollo (IDE ) como en la parte del servidor.
Saludos