Agregando Epiciclos?: Java todavia tiene futuro?
Vas a construir una nueva aplicación.. si eres como yo alguien que disfruta de las ventajas de la reutilizacion que te dan los proyectos opensource, y te estan pidiendo la tipica aplicacion web que tanto se acostumbra en estos tiempos... que haces?
Pues desde el principio ya estas pensando: Spring (o Weld si queres probar algo mas nuevo) para integrarlo todo, JPA para guardar en la base de datos... JSF, Wicket o Tapestry para la interfaz... y si tengo que poner mucha interactividad con Javascript? pues DWR!
Y construyes tu aplicación... Inclusive escribes un script de Ant para poder generar el .war que subiras (de forma tambie automatizada) al servidor de produccion...
Ignoremos por un momento los problemas que hayan podido surgir durante el desarrollo, y pensemos que llego el dia de finamente entrar "en produccion":
La aplicacion ya esta corriendo... y se detecta un bug en una pantalla, nada complicado, simplemente algunos errores de ortografía, asi que haces otro .war y lo subes a produccion... sonries al pensar que puedes hacerlo por que evitaste guardar los archivos que los usuarios suben al sistema en la misma carpeta de la aplicación, de no haberlo hecho, estarías en problemas. El .war termina de cargarse... cuando te avisan que hay mas "mini-correcciones" que subir... después de la 5 vez que haces esto, tu jefe te llama para decirle que el usuario no esta contento con que cada vez que subas una corrección toda la aplicación se detenga, y te pregunta: ¿Que no puedes nada mas subir las correcciones individuales sin detener toda la aplicación?. Le explicas que la aplicación se sube como "todo un archivo .war" que además se corresponde con un "tag" en el repositorio de versiones y que subir todo de un golpe ayuda a garantizar que todas las parte sean compatibles entre si... Tu jefe solo replica: "Que compatibilidad se rompería al mover un acento o cambiar un poco el formato?". Le explicas que el problema es que si abres la puerta a subir los archivos uno por uno, con el tiempo todo se puede llegar a volver un caos, en el que ya no sabrías exactamente en que estado esta lo de producción... Lo cual no lo deja muy satisfecho, y te regresas a tu escritorio con el encargo de "resolver esto".
Cuando me ocurrió esto, despues de pensarlo largo rato, llegue a la conclusión de que la solucion era utilizar "exploded deployment", el problema es que, hasta donde se, ningun servidor JEE soporta que, al subir un nuevo war de una aplicación solo se "apliquen las diferencias" sin detener la ejecución (a menos que las diferencias incluyan un cambio en algun archivo .class). Asi que decidi cambiar la mecánica de las actualizaciones: En ves de compilar el código en mi equipo y subir el .war, decidi descargar el código de tag en el servidor y compilarlo alla, el servidor ya tiene el JDK instalado, solo hacia falta instalarle el cliente de svn y ant. De esta forma pude aprovechar el target de ant para "exploded deployment" que escribi y solo "copiar las diferencias" en la carpeta que Tomcat utiliza para guardar los archivos que componen la aplicación. Una ves resuelto el problema, aprovecho para platicarle la solucion a mi jefe, como al final todo esto es dentro de una misma empresa, no hay ningún problema con tener una copia del código fuente en una carpeta del servidor, asi que el plan queda aprobado.
Parece que el problema esta resuelto, cuando, después de algunos dias, resulta que hay que subir una corrección en el codigo en java. No es nada mayúsculo, unos cambios en algunos mensajes que se emiten desde codigo en java, y algunas validaciones que se tiene que hacer un poco diferente. Afortunadamente, no afecta a las paginas mas "importantes" de la aplicación, asi que mi jefe considera que yo deberia de poder subir la correcciones sin interrumpir el trabajo de los usuarios. Le explico que no es posible, si cambio cualquier cosa en el código, la aplicación se recargara automáticamente, las sesiones se perderán, y todos lo usuarios veran su trabajo interrumpido. Mi jefe entiende que el trabajo de aquellos que usan las pantallas que requieren modificaciones tenga que interrumpirse pero ¿por que el de todos?. Y aqui empiezan los grandes problemas... si lo cambios fueran solo en el HTML o en las validaciones en JavaScript, yo ya le demostré a mi jefe que puedo subir la corrección de inmediato, sin interrumpir el trabajo de nadie, por que ahora que el cambio es en Java si tengo que interrumpir el trabajo de todos? Pues por que las clases requieren que asi sea, a menos claro que uno las tenga aisladas en un classloader distinto (como lo hace Seam y solo para los controladores, si el problema es a nivel de las Entities, estas frito). Existen productos como JavaRebel, pero no se recomiendan para producción (son solo para hacer comoda la vida del desarrollador) y además requieren de que se programen "plugins" de compatibilidad con el (los) framework que hayas utilizado para construir tu aplicación. Le explico todo esto a mi jefe, que me hace la observación de que el ha visto varios proyectos en Java que no tienen este problema...
Le pido que me muestre uno de ellos: Me dice la ruta el SVN de donde descargarlo y asi lo hago... Al examinar el código, me doy cuenta de que no usa Spring, ni DWR, ni JSF, Wicket o Tapestry, es mas, no usa JPA o alguna version de Hibernate! Solo usa cientos y cientos de archivo ".jsp" (y un .jar con una taglibrary para trabajar con JDBC mediante etiquetas). Que desordenada arquitectura! Podrían pensar algunos... No aprovecha los últimos a avances en Java! (Podrían pensar otros), No tiene ni una clase, ni siquiera es código orientado a objetos! (Pensarían otros mas). Pero.. sin embargo, puede hacer eso que no los últimos frameworks opensource orientados a objetos NO pueden hacer: Recargar cualquier parte de la aplicación instantáneamente, sin afectar al resto de la aplicación. En una aplicación realmente grande, esa característica puede ser crucial...
Se supone que hemos avanzado mucho desde los dias que que escribiamos todo dentro del JSP, ahora utilizamos patrones como MVC, ORM, IoC, etc (que de hecho son mas antiguos que los JSP, pero esa es otra historia), pero nuestras aplicaciones se han vuelto rígidas, en un afan por mejorar nuestra productividad de desarrollo, la comunidad de desarrollo de Java ha creado bibliotecas y bibliotecas de componentes, hasta bibliotecas para integrar bibliotecas (como Spring), se han creado grandes y poderosos frameworks, que, sin embargo, se derrumban a la hora de enfrentarse con el dinamismo una simple aplicación en JSP...
Alguna ves han escuchado la expresión "agregando epiciclos"? En tiempos de Ptolomeo. Se creía que la configuración de la tierra y los objetos en el cielo era muy distinta a la que se conoce ahora... Se creai que la tierra era el centro del universo y que los planeta giraban alrededor de la tierra, pero conforme las observaciones de planetas empezaron a hacerse mas precisas, resulto que no coincidían con este modelo... Cambiaron los astrónomos entonces el modelo? Noo!!! lo que hicieron fue agregarle mas círculos, y mas círculos (epiciclos), con lo que cada vez se reducían mas la imprecisiones, pero nunca llegaban a desaparecer... No fue sino hasta muchos años después que Kepler demostró que todo el modelo estaba mal: No importaba cuantos epiciclos se agregaran, nunca coincidirían con las observaciones.
Siento que eso mismo esta pasando con Java, la comunidad agrega cientos de bibliotecas de componente, y sin embargo, como Java no se concibió como una plataforma en donde las diferentes piezas que componen aun programa puedan recargarse individualmente, el mantenimiento de una aplicación se complica, y no importa que tantos epiciclos agreguemos, muy probablemente no estemos mas que alejándonos cada ves mas de la solucion: Como la idea de que las clases individuales puedan recargarse es ajena a las raíces de Java, todos estos nuevos frameworks solo causan mas enredos en la madeja: Recargar una @Entity de JPA no es nada fácil, hay que notificarle al EntityManager y al EntityManger factory que es necesario reconstruya toda su configuración interna... Lo mismo pasa con las configuraciones internas de Spring, y DWR... ninguno de esos proyectos parece estar preparado para lidiar con ese nivel de dinamismo...
Y mientras tanto, PHP, Ruby, Groovy y Jaxer van extendiéndose lentamente... hasta C# 4.0 tendra soporte para comportamiento dinámico... Sera posible todavía rescatar al modelo de Java? (Tal ves si, por ejemplo, Oracle comprara a ZeroTurnaround y agregara a JavaRebel en el core de la JVM?) o es momento de escuchar a los Kepler de nuestra época... y cambiar "en masa" a un lenguaje diferente? Yo ya jugue un rato con JRuby y no me gusto mucho.. .Groovy no esta tan mal, pero todavía se siente muy verde... Scala me gusto mucho mas, pero tampoco siento que este tan maduro como debería (y aunque la sintaxis me encanta (y que use static typing me encanta aun mas), solo cuenta con el dinamismo suficiente por que, como les gusta a los inventores de JavaRebel, su producto es gratis si usas Scala, si un dia se pelean, se le acabo el dinamismo a Scala), tal ves Quercus (el PHP basado en la JVM) se a la respuesta para el futuro? Lo dudo...
¿Que opinan ustedes?
- luxspes's blog
- Inicie sesión o regístrese para enviar comentarios
Procesos
Algunos de los problemas que comentas no son exclusivos de Java. Una aplicación ASP.NET actualmente también hay que reiniciarla cuando se hacen cambios en una DLL (aunque creo que no para los aspx).
JBoss soporta los exploded wars, puedes poner tu app.war como directorio en vez de archivo y si reemplazas un jsp o jsf o algo similar ahí dentro, solamente eso se recompila. Para ciertas clases hay recarga dinámica, dependiendo también del framework que uses (por ejemplo Tapestry permite que sustituyas una clase de una página o componente y la recarga al vuelo sin reiniciar la aplicación, pero no puedes hacer lo mismo con algún DAO, entidad, etc).
En cuanto a la parte de que tienes que hacer una mini-corrección y luego otra y luego otra y después de 5 ya vienen las quejas porque se está reiniciando la aplicación constantemente, eso es una falta de control en los deployments y en el manejo del mantenimiento de la aplicación. Una vez que ha sido puesta en producción, cuando se encuentran bugs primero hay que evaluar la gravedad del mismo (falta de ortografía en una página no es igual de grave que pérdida de integridad en datos por transacciones corruptas, por ejemplo). Se arreglan los bugs en desarrollo conforme vayan saliendo pero se programa una actualización de la aplicación, en horas de inactividad de la misma, o si se sabe ya cuando hay la menor actividad posible, para uno de esos momentos, pero debe ser algo programado y se puede anunciar en el sitio.
Debe haber un proceso para el momento de la actualización: poner una página de "lo sentimos estamos en mantenimiento", bajar la aplicación, respaldar datos si es necesario, respaldar WAR, JARs, EARs, etc, aplicar parches si es necesario a base de datos, sobreescribir los JARs/WARs/EARs que sea necesario, levantar la aplicación en modo interno, revisar que funcione bien y ponerla al aire nuevamente.
Para los bugs muy serios hay que programarles fecha muy pronto; para bugs poco graves como lo de una falta de ortografía, puede ser mejor aplazarlo un poco por si salen otras cosas y hacer un mantenimiento posterior que abarque varias correcciones, no solamente arreglar un bug menor.
Si no tienes un control sobre las puestas en producción, parches, actualizaciones, etc, vas a tener los problemas que mencionas sin importar el lenguaje o plataforma que utilices, porque no es algo exclusivo de Java sino del proceso (o falta del mismo) que están llevando.
La paradoja anti-ORM
Es cierto que estos problemas no son exclusivos de Java, pero PHP, Ruby, Groovy y Jaxer si parecen ser inmunes a estos problemas... al menos como se les usa típicamente... lo curioso es que Java mismo es inmune... siempre que todo gire en torno a JDBC y JSPs (o que se use JavaRebel)... o inclusive, si se utiliza Tapestry, que como mencionas, puede recargar componentes, lo que hay que hacer utilizar al JdbcTemplate directo desde tus componentes: Evitar los DAOs y las Entities... como quien dice, si usas un ORM, olvidate de la recarga dinámica... Este blog post lo oriente a los problemas ya en producción, pero esta limitación tambien afecta el desarrollo, en una aplicación como la que me inspiro a escribir esto, tarda 5 minutos en recompilarse toda y 18 segundos en arrancar... si hubiéramos evitado usar DAOs, tardaríamos 2 o 3 segundos en ver nuestros cambios... Pienso que eso es un indicador de que algo esta seriamente mal con lo que se considera una buena arquitectura en plataformas como Java... ¿Por que organizar bien tu código a de resultar en incomodidades de este tipo? No debería ser asi... (y de hecho no lo seria si JavaRebel fuera parte intrínseca de la JVM, asi que esto es, en mi opinión, definitivamente un grave error de diseño en Java)
Estoy de acuerdo en que debe haber un proceso para el momento de la actualización, de hecho en este blog post menciono que siempre se genera un tag en svn antes de subir la versión, y es apartir de ese tag que se sincronizan los cambios en producción utilizando la tarea sync de ant, de ese modo tenemos garantia de que lo que esta en producción coincide con nuestro tag (igualmente tenemos una tarea de ant que yo programe que permite respaldar los DDL de la base de datos en archivos individuales por objeto de base de datos). Un control asi quita algo de tiempo, pero es minimo y permite recuperarse de problemas (volviendo al tag anterior) o corregirlos (por que se sabe exactamente que código esta en producción). Pero, cuando se tiene un equipo de programadores que han trabajado con "Puro JSP y JDBC directo" el que tengamos que reiniciar la aplicación por que cambio un query (y la UI que lo presenta al usuario) es algo difícil de aceptar... y si nos ponemos a pensar... por que habrían de aceptarlo?
Pienso que esta limitación es muy probablemente la razon por que aquellos que llegan a disfrutar del dinamismo de PHP o Ruby piensan que programar en Java es como ponerse una camisa de fuerza... y lo triste es que no tiene por que ser asi... (lo que ZeroTurnaround vende debería ser parte del core de la JVM)
Ojala este problema se resuelva pronto, por que el descontento seguiría creciendo (cual creen que es el bug mas votado de la implementación EJB3 de JBoss?), en ves de agregarle closures a Java (o haberle agregado generics en 1.5), Sun (u Oracle) deberían preocuparse por lo difícil que resulta lidiar con un problema que esta "resuelto por default" si se usa otra plataforma (Ruby, Php, Perl...)... o si se evita lo que se supone que es el modo mas moderno y mejor de hacer persistencia de datos: los ORMs...
La paradoja anti-IoC: Y tambien hay que evitar Spring :'(
Y probablemente no solo hay que evitar los ORMs... tambien los frameworks IoC, como Spring (o el super reciente y estandar Weld (JSR-299 )) que no son capaces de lidiar con la redefinicion de los beans "en caliente" sin desechar todo el contexto de componentes...
Organización y gestión de TI
En la compañía
¿Está separada la (operación y soporte) del área de desarrollo?
¿Hay un proceso para hacer el mantenimiento a los sistemas?
¿De qué hora a qué hora debe dar servicio a los usuarios el sistema?
La tecnologia deberia ayudar, no crear mas problemas
¿Está separada la (operación y soporte) del área de desarrollo?
Si, estan separadas, aunque cuando los sistema son nuevos, pasa un buen rato entre que lo "soltamos" de desarrollo y se lo dejamos a "soporte" (esperar que puedan lidiar con el cuando esta verde suena bonito, pero no funciona en la practica, sobretodo con sistemas medianos a grandes.
¿Hay un proceso para hacer el mantenimiento a los sistemas?
La mayoria de los sistemas no lleva un proceso estricto, la mayoria son pequeños, simples, y los problemas se resuelven "simplemente copiando el .jsp con la corrección en producción" (no me gusta nada, pero asi es la realidad, no le importan nuestras preferencias), por supuesto, cuando los sistemas son grandes, se hace mas fácil justificar el llevar un control mas estricto (con tags en subversion, instalaciones controladas por los mismos, etc).
Se esta haciendo un esfuerzo de introducción de control en este sentido, pero aun con un proceso claramente definido y que todos usen queda la pregunta: Por que, si todo estuviera programado en PHP/Ruby/Jaxer..., después de seguir el proceso ordenado, podríamos actualizar afectando solo a lo usuarios que utilicen las pagina modificadas, pero, como estamos usando Java, tenemos que amolar a todos? Por que Sun despericia recursos en cosas como closures, y no mejor mejora el proceso de deployment para todos los servidores JEE?
¿De qué hora a qué hora debe dar servicio a los usuarios el sistema?
Depende del sistema, generalmente es de 8 a 5, y ciertamente acostumbramos hacerlos cuando el usuario ya no este usando el sistema, pero la misma pregunta surge una y otra ves: No se suponía que todos estos patrones y modernas bibliotecas deberían facilitar nuestro trabajo? Como es que con "solo JSPs" puedo subir correcciones en cualquier momento, pero con esta moderna arquitectura, me veo forzado a reiniciar todo?
Separación
Puedes poner tus DAOs en un JAR aparte; Spring te permite poner en un contenedor JEE un application context para que se publiquen como EJB's (con un poquito de configuración adicional). Si publicas así tus DAOs, puedes hacer redeploy de tus JSP's y cosas así porque tendrías en tu WAR un application context que para los DAO's y todo eso solamente tiene proxies para conectarse a los DAOs por JNDI. Así el redeploy de la pura aplicación web se agiliza, además de que puedes usar los mismos DAOs desde varias aplicaciones web.
Re: La tecnologia deberia ayudar, no crear mas problemas
Muy probablemente la solución quede fuera de tus manos, sería una labor de dirección de sistemas.
>¿Está separada la (operación y soporte) del área de desarrollo?
>pasa un buen rato entre que lo "soltamos" de desarrollo y se lo dejamos a "soporte"
Presiento que es un No están separadas de manera eficiente el área de operación y desarrollo.
>¿Hay un proceso para hacer el mantenimiento a los sistemas?
>La mayoría de los sistemas no lleva un proceso estricto
La respuesta es un No
>podríamos actualizar afectando solo a los usuarios que utilicen las paginas modificadas
Java te permite construir aplicaciones modulares J2EE para aislar que todo el sistema se afecte al mismo tiempo, esto indica que falta un esfuerzo en revisar la arquitectura de las aplicaciones o en hacer proyectos de mantenimiento correctivos a los sistemas actuales.
>Por que, si todo estuviera programado en PHP/Ruby/Jaxer...,
En mi opinión, esto sería trasladar el problema de un lenguaje a otro, la tecnología sirve como está hecha. Sea Java, php o .net para necesidades diferentes.
>¿De qué hora a qué hora debe dar servicio a los usuarios el sistema?
¿El proceso asegura que sea estricto el cierre para dar el mantenimiento adecuado?
La solución sería revisar y depurar los procesos de liberación, operación y mantenimiento, etc.
Esto significa que no por ser tecnología no se requiere administración.
Existen muchas metodologías CMMI, ITIL, Moprosoft, etc. que les pueden ayudar a poner orden en esos procesos, si y solo si siempre y cuando sean implementadas de manera correcta.
Saludos =)
Pero sigo sin poder recargar los DAOs y Entities... no?
Si, pero eso.... no resuelve mi problema central (o si?) sigo sin poder recargar mis DAOs cuando hayan cambiado...
La tecnologia debe reducir problemas humanos, no aumentarlos
Cual solucion? La direccion de sistemas no puede hacer que JavaRebel sea parte de la JVM...
Probablemente tienes razon en que las areas de operacion y desarrollo no estan separadas de forma eficiente... ahi si estoy de acuerdo en que es mas que nada un problema de economia y organizacion, pero el problema que expongo aqui no es relacionado con la parte humana del problema. Si el sistema estuviera hecho a base de puros JSPs y JDBC (o en PHP, etc) el problema expuesto en este blog post no existiria.
No veo el sentido afirmacion de "En mi opinión, esto sería trasladar el problema de un lenguaje a otro, la tecnología sirve como está hecha. Sea Java, php o .net para necesidades diferentes.." Si me paso a PHP, Ruby (o a una hipotetica futura JVM optimizada por Oracle tras adquirir ZeroTurnaround) el problema desapareceria (Ok, no del todo, las bibliotecas como JPA o Spring tendria que actualizarse para utilizar la nueva API de recarga de ZeroTurnaround, pero una ves hecho eso, el problema desapareceria).
No veo tampoco la relacion con lo estricto o no del cierre del sistema, el punto de este blog post es que con otra tecnologia, puedo tener cambios por modulos, instantaneamente, sin afectar a aquellas personas que no estan usando los modulos que han sido alterados, con Java no... ( a menos que evite usar JPA, Spring, etc, etc)
Estoy de acuerdo en que el proceso de administracion del sistema debe llevar un orden, pero eso no deberia de utilizarse para justificar las limitaciones tecnologicas de la plataforma.
DAOS en varias aplicaciones: Empeora situacion?
Mmmm, el compartir DAOs entre aplicaciones... agrava el problema no? por que ahora cuando uno de esos DAOs cambie, no solo voy a tener que detener 1 aplicacion web... si no varias... :-(
En mi opinión, esto sería trasladar el problema de un lenguaje a
Si me paso a PHP, Ruby (o a una hipotética futura JVM optimizada por Oracle tras adquirir ZeroTurnaround) el problema desaparecería
Estoy de acuerdo en que el proceso de administración del sistema debe llevar un orden, pero eso no debería de utilizarse para justificar las limitaciones tecnológicas de la plataforma.
No veo tampoco la relación con lo estricto o no del cierre del sistema, el punto de este blog post es que con otra tecnología
1. Si el problema desaparecería y es un factor crítico del proyecto faltarían una serie de justificaciones técnicas que respaldaran eso para el caso particular.
2. Un buen amigo me dijo una vez. No traslades un problema humano a la tecnología.
¿Hasta dónde es válido exigirle a la tecnología para que un proyecto no se nos vaya de las manos?
Independientemente del lenguaje si un cambio no está bien validado el sistema generará errores y otras perdidas.
3. El cierre estricto del horario de servicio del sistema te permite que al no haber usuarios en el sistema tengas oportunidad de hacer y deshacer en el servidor. Con lo que no importaría que tuvieras que hacer re-deploys. Si el sistema debe ser de alta disponibilidad hay maneras de hacer esto sin afectar a los usuarios.
3. Si el tema de discusión es que le hace falta a la maquina virtual o como podría mejorarse un Web Application.
Es cierto hasta cierto punto si eclipse puede compilar y refrescar el ambiente podrían haber mecanismos que nos facilitaran el deployment.
RE:DAOS en varias aplicaciones: Empeora situacion?
SOA
No te entendieron
Planteaste una situación: La tecnología debe reducir problema humanos no empeorarlos. La cuestión que planteas va más bien hacia la filosofía de la ciencia y tecnología. Y las respuestas que te dan son sobre administración. Por eso dicen que los ingenieros son cuadrados. No creo que sean las respuestas que buscas , puesto que has de saber con claridad sobre los momentos y las formas en que se da mantenimiento a un sistema. No eran las respuestas que buscabas. . Me parece muy interesante el concepto (y el fracaso) de epiciclos y la analogía muy válida que haces con Java. Lamentablemente te envolvieron en otra discusión bien diferente de la que tenías en mente. Creo que vas tener que buscar en otros foros. Saludos.
Volvi a leer...
Cierto, la tecnologia no deberia complicar la vida, pero vuelvo a leer el post original y lo que entiendo es un problema tecnico de recarga de modulos/clases para resolver las necesidades de una aplicacion que cambia constantemente, no veo la exposicion de un tema filosofico.
Siento que eso mismo esta pasando con Java, la comunidad agrega cientos de bibliotecas de componente, y sin embargo, como Java no se concibió como una plataforma en donde las diferentes piezas que componen aun programa puedan recargarse individualmente, el mantenimiento de una aplicación se complica, y no importa que tantos epiciclos agreguemos, muy probablemente no estemos mas que alejándonos cada ves mas de la solucion
Apoyo el comentario de alguien por ahi, donde dice que se esta trasladando el problema de diseño de una aplicacion al diseño de un lenguaje.
Por que habria que cambiar en tiempo de runtime los modulos de una aplicación?
Intuyo 2 razones:
1) Por que el sistema no esta terminado. Se libero un sistema que todavia le falta terminarlo y se quiere hacer sobre la marcha.
2) Por que no ha sido bien diseñado. Tal vez java u otros lenguajes no han sido diseñados para recargarse, pero si detectas que esta va a ser la caracteristica del sistema, puedes diseñar y crear el sistema de tal manera que las reglas de negocio no deban estar en codigo y modificarlas cuando se requiera.
Tal vez una caracteristica de recarga ayudaria en este tipo de necesidades pero que porcentaje de aplicaciones en la industria son desplegadas de esta forma, que motive a aplicar una "mejora" de recarga?.
Saludos
Mala elección
En todo caso si desde el principio se sabía que era un requerimiento estar actualizando constantemente la aplicación sin tener downtime, entonces se hizo una mala elección de plataforma; con erlang no hubieran tenido el problema. Sí, hay una curva de aprendizaje. Sí, hubieran tenido que hacer muchas cosas de cero porque no hay tantas librerías y componentes como para Java. Pero puedes sustituir código en una aplicación que está corriendo sin tener que reiniciarla. No se puede tener todo. Una plataforma que lo hiciera todo, creo que no sería especialmente buena en nada.
Terminado? Eso no existe: El CAMBIO es la UNICA constante
Se libero un sistema que todavia le falta terminarlo y se quiere hacer sobre la marcha? Me encanta cuando los programadores hablamos de software "terminado", el software "terminado" es como terminar de escribir el valor de PI. El software (casi?) nunca esta terminado, a menos que sea un programita que se hizo para una tarea en la escuela, el usuario siempre va a pedir un cambio mas, una característica mas, otro reporte, un reacomodo de la interfaz, otro color en las pantallas. Siempre ocurriran cambios en la el ambiente que haran que tengas que cambiar el software.
Tienes razon en que algo no esta bien diseñado, y en esta caso, son las bibliotecas de componentes mas modernas de Java (como JPA), que no esta diseñadas para la realidad que siempre cambia.
¿Que porcentaje de aplicaciones en la industria son desplegadas de esta forma? Todas las hechas en PHP, Ruby, Perl, Jaxer, Groovy/Grails, JSP (sin JPA), Tapestry (sin JPA), JSF (sin JPA), las de aquellos que hayan comprado JavaRebel... etc, etc, etc. Creo que si sacaramos un porcentaje, nos daríamos cuenta de lo raro que es tener una plataforma que no puede recargar partes de la aplicación... no creo que seamos mayoria los que tenemos que sufrir este problema... pero como ya nos acostumbramos pensamos que esta "bien" y hasta buscamos razones por la que esta "bien" que las cosas sean asi.
Mala eleccion: Pues ahi si ni que decir
Pues si, pero lo gacho es que JavaRebel demuestra que es posible hacer que Java re-cargue dinamicamente las clases... sin tener nisiquiera (al parecer) que moverle a la maquina virtual, con puro manejo de class loaders y reflection y no se que tantos choros avanzados los cuates de ZeroTurnaround hicieron "lo imposible"... Por que pierde el tiempo Sun en decidir si le pone closures o no a Java, y no mejor hace mas robusta la plataforma, con suporte nativo para recarga de clases y aislamiento de procesos?
Ciertamente estaria chido hacer una aplicacion en Erlang... pero pues cuando hasta con PHP se tiene un comportamiento mas dinamico que con Java... pues da como que da tristeza no? :'(
Y pues si, es una mala eleccion ahora en retrospectiva... supongo que al final caigo en lo mismo que critico en los otros, me olvido de que el futuro es incierto, y la mejor arquitectura no es solo la que te permite escribir un codigo elegante y comodamente, si no la que te permite cambiarlo rapidamente....
No creo que necesitemos un super lenguage... solo necesitamos recordar que las cosas cambian... Java casi esta bien.. hasta se puede comprar un plug-in que hace que sea dinamico... lo que me da tristeza (pero en el fondo no me sorprende) es que Java no halla resuelto esta limitacion hace varias versiones, y en vez de eso ultimamente simplemente parezca correr detras de CSharp diciendo "yo tambien voy a poder hacer eso!". Si los ingenieros de Sun fueran y observaran, un ratito, el trabajo que realizan los programadores "en el campo" todos los dias (y no solo los que programan en Java, si no de varios lenguajes, para poder ver las limitaciones a los que son ciegos "por el efecto del gato en el monasterio", sus prioridades serian muy diferentes.
Patentes, Software Libre, costos...
Para echarle más leña al fuego: yo creo que Sun técnicamente podría integrar lo que JavaRebel hace; pero seguramente ZeroTurnAround tiene varias patentes alrededor de JavaRebel y por lo tanto ni Sun in nadie puede implementar algo similar en USA. Y en México y Latinoamérica nos gusta mucho clamar por el software libre y decir que es la neta, pero nomás para usarlo; nadie se va a aventar algo como JavaRebel en software libre aquí, aunque sea perfectamente posible.
O, simplemente puedes decirle a tus clientes o a tus jefes o a quien sea, que se dejen de tacañerías y paguen por la licencia de JavaRebel para que ya puedas hacer lo que quieren como lo quieren y cuando lo quieren. Entiendo las razones por las que tú quieras una versión libre de JavaRebel, pero las razones de tus clientes y/o jefes les gusta que uses software libre son bastante claras: se ahorran una lana. Así que abre tu Excel (o preferentemente, tu Calc de OOo) y escribe tooodos los paquetes que estás usando (Eclipse, NetBeans, Spring, JBoss, PostgreSQL, Linux, MySQL, etc etc etc etc) y ponles al lado el equivalente en software propietario (IDEA, Visual Studio, Websphere, Weblogic, Oracle, SQLServer, Windows, etc etc) para que vean lo que se han ahorrado hasta el momento y lo comparas con el precio de JavaRebel a ver si ya con eso aflojan para la licencia.
Y en paralelo pues si investigas cómo es que JavaRebel hace lo que hace, y buscas si alguien en Europa está haciendo algo similar, podríamos ayudar...
Software interminable
Bueno si tienes un proyecto de software interminable, tienes que ver el lado amable: mientras sigan pagando por esos cambios, todo está bien, no?
Lo que no se vale es que se pongan a pedir cambios y cambios y más cambios mientras retienen el pago de lo que ya entregaste, con el pretexto de que no está bien.
Y antes que digas que eso es irremediable: cuando haces tu plan de trabajo, gráfica de gantt etc (aunque sea pura ciencia ficción, ya sea por tu culpa o la del cliente), programas entregas parciales con cierta periodicidad, aunque sea juntas para ver los avances. En esas juntas deciden si lo que se lleva está bien o no. Si lo que se lleva está bien, que te firmen una carta afirmando eso; si no está bien porque entendiste mal o lo que sea, ya corriges solamente lo de la última entrega. Si pasan varias iteraciones en el primer ciclo, de plano estás muy mal o el cliente no tiene idea de nada y ninguno de los dos va a seguir contento con ese proyecto así que lo mejor será cancelarlo.
holas ya que tocas el tema
de las entregas y que te firme el cliente si esta conforme podrias postear algun formato o idea de que es lo que debe de decir ese documento?
Ad hoc
No tengo un machote ni formato predefinido para ello. Pero no es tan complicado, solamente haz una carta como si fuera de parte del cliente que diga el típico "por medio de la presente acepto la entrega parcial de parte de $CONSULTOR referente al proyecto $PROYECTO el día $FECHA, en el entendido de que cualquier cambio posterior a lo que fue aprobado hoy, causará retrasos en la fecha de entrega así como incrementos en el costo del desarrollo" y que te lo firme el cliente y le anexas a la carta una lista de lo que revisaron en la junta (las pantallas, páginas, módulos, reportes, etc que hayan visto y que ya hayan indicado que ya están).
En caso que algunas cosas estén bien pero otras no, se puede tener un formato con la lista de los módulos y que solamente firmen de aceptado en lo que ya aprobaron, dejando lo demás como pendiente. Esos documentos los guardas para que cuando te digan "ah no ahora quiero la base de datos en verde limón" les muestras que ya la habían aprobado en una junta anterior y que estaban de acuerdo en que fuera azul marino.
La finalidad no es que te niegues a hacerle cambios, sino mostrarle al cliente que ya te había aceptado una parte del proyecto de una manera y ahora quiere modificaciones, porque la bronca es cuando niegan que son modificaciones y dicen que nunca estuvo bien y se les olvida que ya habían dicho que estaba bien. Si no pueden negar que son modificaciones, tienen que aceptar entonces que habrá un retraso en la fecha de entrega programada originalmente y que habrá un costo adicional por modificar algo que ya habían aceptado. Y obvio eso no te salva de que el cliente se ponga necio y te diga que no le importa y a ver cómo le haces y no te paga hasta que le hagas los cambios; por eso las entregas parciales deben ir de la mano con pagos parciales; de esa forma si decides abandonar el proyecto tienes algo de documentación que puedas usar para justificar tus acciones, además de que no habrá sido una pérdida total de tiempo, dinero y esfuerzo, puesto que al menos habrás recibido algún pago. Y dado que el cliente ya te ha pagado algo en cada entrega parcial, seguramente no querrá perder ese dinero tampoco, por lo que generalmente ya no se ponen tan necios como cuando ya tienes el 90% del proyecto hecho y no te han pagado nada (de hecho ahí es cuando normalmente los clientes se ponen necios; saben que tú tienes mucho más que perder, porque ya invertiste mucho tiempo en ese proyecto y no has recibido ni un peso, en cambio ellos pues pierden tiempo pero si cancelas y no entregas ni una línea de código, pueden empezar de cero, pues no les ha costado un centavo hasta el momento).
Quien se queja? El cambio es la unica constante
Yo no me quejo de que sea interminable... como dices, mientras sigan pagando, que sigan pidiendo cambios...lo que no me gusto fue el comentario de jiturbide de que una plataforma con recarga no seria necesaria si yo terminara el software perfectamente. Lo curioso es que muchos programadores no se de cuenta que el software no se "termina", el cliente siempre puede pedir mas... asi que entre mas rígida tu plataforma de trabajo, mas problemas tendras. Luchar contra el cambio es tener la batalla perdida desde le principio, por que lo unico seguro, es que las cosas van a cambiar. Y te conviene que cambien, por que, mientras quieran mas características, te seguirán pagando. Y precisamente, como quisiera que me sigan pagando, quisiera que hubiera un modo de poner en producción los cambios que me piden sin tener que interrumpir su trabajo...
Ahora, si quieren cambios pero no pagan... ese es material para otro blog post... ;-)
Cambios
De acuerdo en que el software siempre cambia. Y las causas muchas veces ni siquiera son inherentes al software; un desarrollo largo inevitablemente sufrirá cambios de requerimientos porque las necesidades de quien lo pidió pueden cambiar por razones completamente ajenas al software (cambios en legislaciones, tendencias tecnológicas, nuevos competidores, nuevos inversionistas, cambios en visión, etc etc etc). Como ya dijimos, mientras sigan pagando, pues de maravilla.
Sin embargo siempre hay que buscar un equilibrio entre la flexibilidad de tu diseño y arquitectura para acomodar cambios futuros (hacer tu aplicación "future proof") y la rigidez necesaria para que algo funcione hoy. Si comienzas con algo tan flexible que pueda hacer casi cualquiera cosa, vas a tener muchos problemas para que haga la primera cosa (y como ejemplo pongo algunos contenedores JEE como Weblogic o Glassfish). Si comienzas con cierta flexibilidad pero enfocado a resolver las necesidades más inmediatas, podrás mostrar algo al cliente y tenerlo contento en menos tiempo (como ejemplo Jetty).
Usé esos ejemplos por el contraste. Jetty es un simple contenedor de servlets, pero hoy en día gracias a Spring y otros frameworks, puedes correr ahí aplicaciones moderamente complejas. En Weblogic puedes poner aplicaciones muchísimo más complejas, armar clusters, cosas así, pero en cuál es más fácil poner una aplicacionsita de 3 páginas (casi casi un "hello world"?) en cuál levanta primero si lo corres en una netbook? (weblogic levantará en una netbook? lo dudo). Y no digo que uno es mejor que otro. A fin de cuentas resuelven distintas necesidades. Pero cuánto tiempo y gente crees que tomó desarrollar Jetty y en contraste cuánto tomó Weblogic...
El truco está en encontrar ese equilibrio. Esa es la parte más difícil de diseñar y hacer arquitectura, y no deja de ser un trabajo que tiene una buena parte de artesanal, de intuitivo, de experiencia, etc.
Volviendo al problema de recargar componentes: se me ocurre la mafufada de poner distintos módulos de la aplicación a correr en distintas JVM's y que se comuniquen entre ellos por RMI o algún mecanismo similar, agregando en ambas puntas de la comunicación lo necesario para fallar con gracia en caso de que se rompa la comunicación. Cuando piden un cambio por lo general es en una sola parte, no? Puedes sustituir el código del módulo en cuestión y reiniciar solamente esa JVM, dejando arriba el resto del sistema.
O tal vez algo similar pero con una sola JVM y usar tus propios class loaders, uno por módulo (con la granularidad que requieras)? Has visto la opción de hacer alguna marihuanada con javassist y/o cglib?
Otra vez yo
Hola luxespes.
Sorry por el comentario pero insisto, de acuerdo a lo que leo, se esta tratando de resolver con tecnologia una problema no tecnologico: malas practicas, un usuario maleducado que no entiende que los cambios deben hacerse al final de una ventana de servicio, problemas de diseño etc.
¿Por que no esperar a reemplazar la aplicación durante el fin de la ventana de servicio? Aunque sea una pausa algunos minutos.
* Eso te ayuda a hacer los respaldos necesarios para hacer un retorno en caso de que algo salga mal. A veces ni siquiera son tus cambios los que pudieran fallar, cuando se introduce un cambio que implica a varias areas puede llegar a pasar que algo le sale mal a otra area y sea necesario retornar el cambio.
* Si la aplicacion convive con otras dentro del mismo server, garantiza que las demas aplicaciones no se vean afectadas por la introduccion de un cambio que parece inofensivo pero en ocasiones disparan problemas.
* Garantizas que los datos que estan siendo modificados no se corrompan por el cambio que se quiere hacer en caliente.
Al final lo mas valioso de un sistema es la informacion. ¿Alguien arriesgaria la operacion para corregir un acento (por ahi lo mencionaron) o meter un cambio que se le acaba de ocurrir al usuario? (A eso me refiero con terminado)
Cuando anote: Cuantas organizaciones realmente trabajan de esa forma? Honestamente en mi caso no conozco ninguna, tal vez he corrido con suerte.
Sorry de nuevo no quise ofender.
Saludos
Suertudo
Pues sí creo que eres bastante afortunado si nunca has tenido un usuario o cliente que quiere que le corrijas algo en el momento; o si nunca has tenido que actualizar una aplicación ASAP porque encontraron un bug ya en producción y te tienes que desvelar corrigiéndolo, probando el cambio y subiendo la actualización sin poderte parar ni a respirar; o si nunca has subido la versión incorrecta de la aplicación y por lo tanto hay que corregir y subir la versión correcta cuanto antes (versión correcta puede ser una versión previa, o una versión configurada para desarrollo y que nomás no corre en producción, o con algún dummy o mockup en vez de un componente real, etc).
Si nunca has tenido todos los problemas excepto el primero, eres un super programador. Pero el primer problema que menciono (que el cliente te pida que actualices en este instante) es ajeno a tus superpoderes, así que en ese aspecto sí eres muy afortunado.
Y no olvides amarrar siempre al gato del monasterio...
Hola jiturbide:
Cual problema no tecnologico? ya lo explique antes, utilizamos tags de subversion para llevar un control de lo que subimos a produccion, tenemos la instalacion automatizada, con scripts de ant que se encargan de sincronizar de manera transparente produccion con un tag, podemos movernos instantáneamente entre releases. Si eso no es suficiente, tal ves deba aclarar que tenemos 4 servidores de pruebas, donde se suben diferentes tags con diferentes avances en diferentes modulos de la aplicacion, hay un equipo de testers que prueba la aplicacion antes de subirla... se hacen backups todos los dias tanto de las bases de datos como las de produccion...
El sistema que me inspiro a escribir esto no es uno pequeño... la cuestion es, que cuando ya todas la pruebas se hicieron, y se tiene listo el tag con la version que se va a subir a producción, el usuario no esta de acuerdo (y francamente yo tampoco) con que si todos los cambios del la version 0.0.20 a la 0.0.25 (los numeros intermedios fueron releases que no llegaron a produccion) fueron solo en el modulo de P, las personas que utilizan el modulo de Q tengan que verse afectadas, ya se hicieron pruebas y se verifico que el modulo de Q no se vio afectado de ningun modo por los cambios en P... por que tengo que interrumpir el trabajo de los usuarios del modulo Q?. Simplemente no hay justificacion que valga, sobretodo por que este usuario tiene sistemas instalados en PHP y en JSP+PlainJDBC en los que se realizan este tipo de actualizaciones varias veces al dia, entre modulos independientes y sin ningun problema.
Ciertamente subir las cosas a la carrera y sin cuidado al servidor acarrea problema, y precisamente por lo facil que resulta hacerlo en la mayoria de las plataformas, me ha tocado ver verdaderos caos en los que se pierde el control de la relacion entre lo que esta en el scm y en produccion. Casos asi ameritan un control mas estricto de lo que se sube a produccion, ese si es un problema humano, que se resuelve con organizacion humana, no solo tecnologia (aunque ciertamente ayudan los tags y el ant), pero eso no deberia usarse como excusa por parte de los fabricantes de servidores JEE para hacer las instalaciones mas complicadas de lo que ya son.
Otros puntos importantes:
Y por que si esperar al final de la ventana de servicio? Por que siempre se ha hecho asi? No digo que no haya sistemas para los que amerite esperar... pero y para los que no? Y si se detecto un muy grave que tiene que resolverse a la brevedad? Aparte del tiempo que ocupa corregirlo, ademas tengo que sumarle el tiempo que la plataforma me hace perder por su inflexibilidad?
Y si la aplicacion no convive con otras en el mismo server? En el caso de la aplicacion que me inspiro a escribir esto, el servidor es para ella solita, asi que esas preocupaciones no existen. Y eso me lleva a otro punto.. por que se ven afectadas las varias apliaciones corriendo en un mismo server JEE? Pues por que Sun piensa que es mas importante correr detras de CSharp que implementar Process Isolation (otra limitacion de la plataforma... un gato mas que amarrar en el monasterio...).
Y finalmente... y si ya hice pruebas de que los datos no van a ser modificados? y si los nuevos cambios son para partes de la aplicacion que son "solo lectura" (como reportes)? Como justificarias entonces interrumpir el trabajo de los otros modulos?
Quiza la diferencia es como yo veo las actualizaciones... para mi cada actualizacion es distinta (para ti todas son iguales), algunas se pueden subir en caliente, y otras no (para ti ninguna se puede), todo depende de las implicaciones que tengan... la plaforma debería permitirla subir todas en caliente, y deberia quedar como mi decision si es o no peligroso subir una determinada actualizacion en un determinado momento. Esa decisión no deberia tomarla la plataforma por mi, por que no puede saber cuales son mis necesidades en un momento dado.
Finalmente... jiturbide, no te preocupes, no me senti ofendido por tu comentario, solo un poco decepcionado de lo facil que es para nosotros como desarrolladores caer en la trampa de creer que una limitacion en la plataforma este justificada con lógica circular: Debe ser complicado instalar en un servidor JEE por que es complicado instalar en los servidores JEE. Francamente, yo tambien era ciego a este tipo de limitaciones, hasta que vi la lo increíblemente simple que era (desde un punto de vista netamente tecnologico) poner en produccion una aplicacion en PHP o en JSP+JDBC o en...
Ok man
Ok, luxspes.
Ezamudio: Las situaciones que mencionas las conozco, lo que no he visto es que un cambio controlado se pida hacerlo con una sustitucion en caliente, en lo particular prefiero ir a la segura y por eso el comentario de ser afortunado.
Considero que caso del reemplazo de componentes es una necesidad particular, para algunos sera deseable para otros no necesaria. Seria valido cuestionar los frameworks actuales y el futuro de Java por que no cubre una necesidad particular? Sobre todo cuando tienes opciones de productos y lenguajes que han mencionado, o tiempo para diseñar la aplicación como alternativas de solución?.
Saludos
Cuestionar? Que tal competir?
Que si es valido cuestionar los frameworks actuales? No lo se... lo que se es que Ruby se llevo un buen mordisco de los cliente de Java, PHP tiene otro buen mordisco.... y la mayoria de las "aplicaciones web en Java" tiene una gran parte de su codigo escrito en un lenguaje dinamico (JavaScript) y un una tecnologia dinamica de descripcion de paginas (JSP).
Si es valido o no cuestionar a Java... pues si los nuevos dueños de Java piensan que lo mejor que puede hacen Java es decir "Ser dificil de instalar es bueno, por que es bueno ser dificil de instalar" y dejar las cosas como estan... pues alla ellos... en mi opinion, si no resuelven estos problemas, la competencia se los va a comer... y como a mi me gusta mas Java... (aunque quiza no lo paresca) pues me pareceria triste que desapareciera... pero si asi tiene que ser... ni modo
Por otro lado... Oracle no tiene buen fama por la usabilidad de sus productos, tienen fama de robustos, de buen desepeño, y muchas otras cosas positivas, pero nadie dice "instale y configure optimamente Oracle y fue re-te-facil" asi que es posible que haciendose el dificil se pueda hacer buen dinero... aunque a mi no me guste ...(Igual se puede hacer dinero vendiendoles gatos para amarrar a los monasterios no? Hasta la cuerda para amarrarlos puedes vender... ;-) )
Oracle
Lo que dijiste es como la filosofía de Oracle, no? "Ser dificil de instalar es bueno, por que es bueno ser dificil de instalar" ... es casi una cita de Larry Ellison.
Ruby le comió terreno a Java por RoR pero ya fue demostrado que no es escalable (es muy tarde y no voy a buscar la liga ahorita, pero ya salió a la luz que no escala bien, con muchas sesiones y cosas así, truena y lo tienen que estar reiniciando a cada rato, al grado de que el parche que le pusieron a Ruby fue... adivinaste! quick turnaround).
Continuous Deployment, In Practice
Parece que yo no soy el unico loco que piensa que uno deberia liberar tan seguido como pueda.... Ojala los nuevos dueños de Java tomen en cuenta esta nueva tendencia.
Interesante artículo
Me gusta mucho que menciona algunos puntos que considero muy importantes: "build in alerts and monitoring" y "build in application level diagnostics". Pero como ya hemos dicho hasta el cansancio en este post, JEE es exactamente lo opuesto: un deployment es todo un ritual. Por eso para ciertas cosas prefiero hacer aplicaciones JSE y construir un contenedor ligero ad-hoc para la aplicación usando Spring. Hay que ponerle un poco más de infraestructura y cambias unas cosas por otras pero a veces termina siendo más fácil de administrar, levanta más rápido, usa menos memoria, etc etc.
OJO: no digo que no hay que usar JEE o que estoy en contra de los contenedores empresariales como JBoss, Glassfish, etc; pero esa tendencia a meter TODO ahí, no me convence.
Mmm antes debes resolver otras cosas
Creo que para llegar a las conclusiones que expones, pasaste por ciertas carencias de arquitectura y procesos de desarrollo de sistemas ( y esto no tiene que ver con java).
1:
Tal parece que olvidaron una de las etapas de desarrollo con más correcciones por parte del cliente se llama Testing.
Así como existe el ambiente de desarrollo, donde básicamente eres tu y tu maquina probando y corrigiendo tu código en caliente, debe existir una etapa de testing donde los clientes o usuarios finales prueban el sistema con todas las correcciones que requieran, donde la información es ficticia y si ha de reiniciarse la aplicación no deberá afectar a nada valioso o importante, asi lo estén ocupando otras personas, "es testing".
De haber hecho bien un ambiente testing, al dejarlo en producción no deberás tener ninguna de las modificaciones sencillas que mencionas, solo serán problemas que no pudiste prever en testing porque las condiciones no las pudiste igualar a las de producción.
Las modificaciones que hace un usuario final , son en testing , si son en producción (algo está muy mal) pregúntate si pudiste preverlo o estuvo en tus manos el que esto no pasará.
Si es un sistema que es tan dinámico debiste elegir otras tecnologías, si por el contrario el sistema va a llegar aun punto donde no van a realizarse modificaciones por un largo tiempo, este sistema no es dinamice sino con muchas correcciones en una etapa del mismo y no son precisamente en producción en donde se deben hacer.
Si encontrarás un super java dinamico o un super JRebel, te resolvería el problema que surgió no por las limitantes de java sino por las carencias de proceso de desarrollo de software que tuviste.
2:
Cambia de jefe, jajaj, o enseñale java, para que tenga una idea de lo que pide jjaa.
Es una razón para remplazo el que te pidan algo y tu solo termines diciendo peros y más peros tecnológicos que solo tu entiendes y sabes.
Los clientes y los jefes quieren soluciones no razones para no cumplir con lo que ellos "simplemente necesitan"
"Es que eso es lo que necesito" -> mata cualquier respuesta-problema-limitante tecnológico, que te puedas inventar.
3:
php. ruby, scala, etc etc y los que puedan aparecer, atienden a un mercado el cual nunca pudo cubrir java, "nunca".
El mercado donde la complejidad radicaba en las capas superiores o de vista, llámese sitios web, donde su mayor problema se resolvía no con patrones de diseño o super tecnologías, sino con un simple script y un archivo.
Jamas podría ver a una empresa sin java donde la complejidad nunca la ve o percibe el cliente, sino esta en las reglas de negocio, procesamiento, integración etc,
php, ruby y el que salga mañana, no están hechos para resolver esos problemas.
El preocuparse por la bandada de lenguajes dinámicos, no es la extinción de java, sino la expansión de esta. Java jamas ha sido líder en el mercado de web, php es el rey.
El problema se le ha dado la vuelta creando el suporte de la JVM para lenguajes de este tipo, don jruby, Quercus, Jython, scala etc. Donde todo ese conocimiento y trabajo plasmado en un montón de jar´s no se pierde, no se tiene que hacer en alguno de estos nuevos lenguajes, sino que se reutilizan creando un puente.
Proyectos pequeños sin complejidad y cambiantes -> productividad - tiempo, grails, python php etc etc.
Proyectos con una complejidad, constante "evolución" detras -> no hay más java, ponle el sabor del helado-web que quieras arriba
Si en java no se resuelve la modificación dinámica que tiene otros lenguajes no significa su extinción sino su expansión.
Tal vez tu necesidad no es java, la respuesta ya la has dicho.
Un mundo ideal....
daynatem...:
1) me encantaría vivir en el mundo ideal en el que vives tu, en el que se trabaja en una empresa a la que literalmente le sobra el dinero, que deja a los testers trabajar durante mucho tiempo reportando bugs, donde ademas, los testers son perfectos y no se les pasan nunca los bugs, donde las fechas de entregas se pueden posponer indefinindamente, y donde puedo facilmente hacer que mis jefes hagan lo que yo quiera y no lo que ellos quieran... ;-)
2) Aqui si no te entiendo, supongo que finalmente estas de acuerdo conmigo dices que: Es que eso es lo que necesito" -> mata cualquier respuesta-problema-limitante tecnológico, que te puedas inventar, bueno pues ese precisamente mi punto, y si lo que el mundo necesita son sistemas dinámicos y robustos, pues lo siento por Java o mas bien, lo siento por cualquier cosa que no sean JSPs+JDBC. (Ahora que si en tu mundo ideal los sistemas son estáticos y no evolucionan, pues que envidia me da! supongo que en tu mundo siguen usando 86-DOS pero como alla los sistemas son perfectos desde la version 1.0, esta mas chido que el Mac OS X de este mundo)
3) No se que decir... ya has programado en Scala? La sintaxis es tan clara que y directa que hace ver a Java como una "acumulación sin sentido de redundantes redundancias sin sentido". Y al mismo tiempo tiene static typing y produce .class tan buenos en terminos de rendimiento como los de Java. A eso le sumas JRebel, y ya tienes una plataforma dinamica con un lenguage elegante, conciso, facil de leer, estricto y eficiente... por que alguien con la lana de Larry Ellison no apoya a Scala? Eso si no lo entiendo... (Por otro lado Scala tambien tiene montones de bug, y en este momento, no es ni remotamente tan estable, ni tiene tan buenas herramientas de desarrollo como Java, pero ni modo, asi es este mundo imperfecto)
Supongo que los programadores no tenemos muy buena memoria... antes la gente se quejaba mucho de Windows, por que cualquier programa que instalaras, tenias que reiniciar la computadora, si un programa se caia, tiraba a todos, si crees que Windows Vista es inestable, es que no te acuerdas de Windows 3.0... ahora tenemos servidores JEE, que cuyo complicado deployment y falta de process isolation resultan en lo mismo... pero pareciera que eso es aceptable, y no debe ser criticado, si no considerado como una "feature"... supongo que este mundo es aun mas bizarro que el ideal del que vienes tu ;-)
no estas equivocado
Hmm bueno este tema ha dado mucho de que hablar y mi opinion llega un poco tarde pero aqui va de todos modos.
Como yo lo veo, el problema que planteas no es algo "común" que suceda en todas las aplicaciones java. Eres el primero que leo que tiene un problema de este tipo por que su cliente es tan cabrón que no quiera que sus usuarios pierdan la sesión y el trabajo que esten realizando en ese momento (que será si acaso algo muy poco por que en con cada acción siempre se guarda la información que no?), y que el deployment del nuevo jar dura si acaso 1 minuto, o me equivoco?
Puedes hacer todo con jsp's para que tu clientesito este feliz y contento con cambios urgentes que te pida que los hagas e instales durante operación, violando las reglas del proceso de desarrollo y tiempo de instalación que en cualquier impresa saben que es cuando no se trabaja (como las líneas de produccion de las grandes transnacionales), pero que va a pasar el día en que a tu cliente se le ocurra decirte: "sabes, necesito que mi aplicacion se comunique por puerto serial con esta maquina que compre que me va a ayudar a en este lado de mi empresa", que vas a hacer? forzar el uso de internet explorer y utilizar activeX para la comunicacion serial? o que pasa es va mas alla y es un usb o algun otro tipo de conector?
Yo creo que mas que buscar una solución a ese problema aislado, deberias intentar convencera tu jefe que establesca ciertas reglas con sus clientes, como que todo cambio y/o correcion requerirá de cierto tiempo de actualización que dejará offline el sistema cierto tiempo, ya si tu jefe no sabe como negociar eso con el cliente, está frito como jefe.
Saludos
estoy equivocado?
Que no es comun? Me pregunto entonces que estaban pensando los de JavaRebel... y los desarrolladores de PHP y... los que usan puros JSPs, los que usan ColdFusion, y etc, etc...
Si necesito acceder al puerto serie? en cada maquina? bueno, pues ya ahi una aplicacion web acaba siendo una mala idea (estan sobrevaloradas las aplicaciones web, en mi opinion), pues supongo que utilizaria JavaComm... igual puedo llamarlo desde un JSP si es que la comunicacion ocurrira en el servidor... y si es en el cliente con un applet (aunque no estoy seguro si sean compatible con JavaComm)... claro que eso no podra recibir actualizaciones en caliente, pero ahi ya lo puedo justificar, por que es algo que seria claramente diferente a una aplicacion web para el cliente.
Problema aislado? bueno si... solo para los que no usan lenguajes o tecnologias mas dinamicas...
Si, estoy de acuerdo en que se deberian hacer acuerdos con los clientes, lo gacho es que como este cliente tiene muchas otras aplicaciones JSP que no tiene problema en actualizarse en caliente, no importa como se plantee, lo que el cliente escuchara sera "como nuestra tecnologia es inferior, no podemos actualizar en caliente, por favor, danos un trato preferencial".
Apache Sling
Ya leiste acerca de este framework de Apache?
Me llama la atención el párrafo:
The embedded Apache Felix OSGi framework and console provide a dynamic runtime environment, where code and content bundles can be loaded, unloaded and reconfigured at runtime. (énfasis mío)
Tal vez solucione tu problema de cargar cosas en caliente?
FakeReplace: HotReplace
Tal ves fakereplace lo consiga...
FakeReplace = forwardInvocation y methodSignatureForSelector
El REDEFINED_STATIC_METHOD que piensa usar el autor de FakeReplace, y se se encarga de manejar y redirigir todas las llamadas a metodos me recuerda mucho a los metodos NSObject forwardInvocation y methodSignatureForSelector de Objective-C... (que a su ves, tengo entendido, derivan de metodos similares en Smalltalk)
Si tan solo Java hubiera sido diseñada para parecerse mas a SmallTalk... Cuando dejaremos de reinventar la rueda? Al menos C# ya va a permitir algo parecido
Si es todo un ritual
Como dice ezamudio, un deployment generalmente es todo un ritual.
En México, muchos hacemos las cosas mal desde el inicio y muy pocos las hacen bien. Quizá de 100, solo menos de 5 hagan las cosas bien, razón por la cual, supongo que en muchas empresas de México, al menos en donde yo trabajo que tiene una división Financiera (Banco) y una división comercial (Tienda), la división del Banco es quien "regula" los deployment y únicamente permite liberar cambios a producción 3 días a la semana después de las 10 pm (salvo que exista un problema crítico que DETENGA la operación de las tiendas, entonces el cambio sube de inmediato.)
Bajo cualquier otra condición es imposible liberar un cambio a producción. Por un lado, estando en los zapatos del Director General de Sistemas de esta empresa, entiendo que aun conociendo las técnicas y herramientas que mencionan para evitar o agilizar el deployment completo de un WAR, causa frío autorizar un cambio a cualquier hora y cualquier día de la semana para sustituir un solo JSP, sobre todo tomando en cuenta que puede ser de algún Sistema que se utilice en México y Latinoamerica.
De momento, yo quisiera tener la facilidad para subir un cambio de algún JSP a cualquier hora y cualquier día de la semana y sea tan sencillo como reemplazar el JSP y listo!! Sin embargo no es así, en vez de eso, forzosamente debemos subir el WAR completo y eso también es todo un rito.... Aun en los días normales de cambios, se deben levantar Folios y conseguir las autorizaciones correspondientes para por la noche desplegar el WAR aunque se trate solo de un JSP.
hay maneras...
Hay maneras de facilitar los deployments. Los sistemas de integración contínua ayudan bastante, pero dependen por supuesto de que se codifiquen pruebas unitarias y de integración; entonces, si haces un simple cambio en un JSP y se ejecuta toooodo el proceso de pruebas y de integración, y sí hay pruebas para ese JSP y pasan bien, entonces nada truena, y por lo tanto todo mundo puede estar más tranquilo de subir el JSP a producción.
Si no hacen eso pues se complica bastante. Y si no tienen ni siquiera una batería completa de pruebas que se ejecuten antes de cada deployment, entonces aunque solamente permitieran hacer deployment en los días de luna llena después de la medianoche, pueden tener muchos problemas.