Adaptabilidad de las plataformas abiertas

Recientemente, tras la impartición de un seminario acerca de Spring Roo, se me vuelve a venir a la cabeza los movimientos que se producen en las comunidades tecnológicas para adaptarse rápidamente al cambio de paradigma. En el siguiente post pretendo explicar los movimientos de la tecnología más “conservadora” Java para adaptarse al cambio producido por la incorporación de tecnologías tales como Ruby on Rails, Groovy y Grails en el ecosistema.

En este juego sería bueno explicar de dónde venimos y hacia dónde vamos. Java, pese a quien le pese, tiene la losa de haber mantenido un histórico de tecnologías que brillaban por su falta de pragmatismo y su dificultad de uso para los desarrolladores. A más de uno se le viene a la cabeza la especificación antigua de los EJB’s. Si soy justo, también he de valorar que hay ciertas especificaciones definidas en el mundo Java, tal como la especificación de Servlets y JSP, las cuales , desde los años 90, no han sufrido grandes alteraciones y cumplen con las necesidades de los actuales desarrollos web.

Ideas y frameworks innovadores

Ahora bien, llega un momento en el que el panorama aparece Ruby On Rails, y ciertamente produce un vuelco en el mundo del desarrollo web, donde parece que dicha tecnología incorpora una mezcla de lenguaje dinámico (con mucho más potencial que el lenguaje Java), prácticas tales como convención sobre configuración (la cual pone en entredicho aquellos componentes que tienes que configurar de manera excesiva en Java), un motor de persistencia (ActiveRecord) cercano al concepto de ORM (Object Relational Mapping), y en definitiva, un framework que presenta una mayor facilidad a la hora de desarrollar aplicaciones web.

Paralelamente a la inclusión de Ruby On Rails, en el mundo Java surge Rod Johnson con un golpe sobre la mesa, reivindicando que las tecnologías tales como los EJB’s no aportan demasiado. En su libro, Rod Johnson aparece con una serie de patrones y buenas prácticas que finalmente, y tras el éxito de su publicación, decide materializar con el proyecto Spring Framework. En paralelo a esta iniciativa, dentro del ecosistema Java, aparecen librerías tales como Hibernate, Quartz, Ibatis, Castor, XMLBeans, etc. que aumentan bastante la calidad de las arquitecturas y desarrollos basados en Java.

Aparece Groovy y Grails

Hace unos años, aproximadamente cuatro, había una lucha encarnecida en el entorno de las personas de Ruby On Rails contra todo lo que empezara por “J”. Bajo mi humilde opinión, creo que en muchas de esas críticas se comparaba el Java de los EJB’s 2.1, contra la plataforma de Ruby On Rails, sin darse demasiada cuenta de que la comunidad Java estaba reaccionando y evolucionando hacia plataformas donde se reducía claramente la complejidad, apareciendo soluciones tales como Spring MVC, que suponía un salto sustancial, comparado con nuestro “querido” pero denostado Apache Struts 1. No obstante, tenían razón, el lenguaje Ruby era un salto sobre el lenguaje Java y la plataforma Ruby, y adicionalmente suponía un salto sobre la plataforma de Java. Pero aquí me gustaría destacar la naturaleza “abierta” de la plataforma Java, la cual permite reaccionar ante el nuevo paradigma. De ahí que aparezca Groovy y Grails, dicho sea de paso como copia absoluta del lenguaje e ideas de Ruby On Rails, pero con la ventaja de que corre de manera nativa sobre la máquina virtual de Java. Así, que como no podía ser de otra manera, garantía de éxito: lenguaje dinámico con un potencial enorme de definir lenguajes específicos de dominio, naturaleza dinámica y flexible, quitando ciertas ataduras que produce el lenguaje Java y con construcciones tan increíbles como los famosos Closures.

En este nuevo panorama, tenemos Ruby On Rails como cabeza de tren y Groovy on Grails que fagocita ideas y que las enmarca en un entorno más interoperable y que permite, por tanto, atraer el entusiasmo de muchos profesionales que aún no habían reaccionado al movimiento Ruby On Rails en el mercado.

Java reacciona: aparece Spring Roo

Por tanto, tenemos cuatro escenarios mayoritarios para desarrollar una aplicación web: PHP, Ruby On Rails, Groovy/Grails y el ecosistema “conservador” Java. Pero, era cuestión de esperar, cuál ha sido el siguiente paso del ecosistema Java, Spring, con la calidad que lo caracteriza, saca a la palestra Spring Roo: una plataforma de desarrollo rápido de aplicaciones que permite realizar aplicaciones desde cero de una manera rápida y sencilla, y donde todo el código repetitivo y aburrido es generado por la plataforma con un enfoque mixto de generación (pasivo y activo). Aprovecha las bondades que ofrece AspectJ y los inner-type declarations (ITD), para permitir disponer de una plataforma totalmente inocua (no presenta ninguna limitación a la plataforma base Java) y se encarga de mantener la coherencia entre los objetos mantenidos por el desarrollador y los componentes generados. Y de nuevo, nos encontramos con el mismo modelo, el “antiguo” Java que reacciona ante los cambios de paradigma ofrecidos por sus competidores en el desarrollo de aplicaciones web.

Bien y ¿Cómo queda Roo contra Grails?, pues para mí, claramente en un empate técnico.  Grails gana en capacidades de su lenguaje, escribo menos líneas de código  y dispongo de un lenguaje con más posibilidades, ahora bien, si de lo que hablamos es de herramientas de ayuda al desarrollo (debugging, asistentes de código), performance, en este terreno creo que actualmente gana Spring Roo. Otro de los aspectos que creo que Roo tiene más conseguidos, es que sus addons no incorpora limitaciones en el uso de frameworks. Por ejemplo, si comparamos el addon de Spring Security de Roo con el de Grails, en el caso de Roo no lo deja limitado, existiendo la posibilidad de usar el potencial de la librería sin ninguna restricción. En el caso de Grails, aparte del plugin da una funcionalidad muy reducida, te impone restricciones en el uso de otras funcionalidades que ofrece el framework.

El futuro de los frameworks

El siguiente movimiento a esperar es que la plataforma Java acabe incorporando un lenguaje más completo y dinámico (incorporación de Groovy al SDK de Java), para poder competir en igualdad de condiciones. ¿Quién se llevará el gato al agua? Sin duda, aquella solución que presente mayor comunidad en el futuro. Mi opinión personal es que en esta batalla Java tiene  algo de terreno ganado, puesto que la cantidad de años que lleva Java en el mercado hace que los profesionales no tengan la misma velocidad de reacción ante los cambios que se producen en la tecnología, y esta estela de profesionales Java harán que alternativas como Roo y la incorporación de un lenguaje más completo y dinámico a la escena, sean los elegidos para el futuro en una mayoría de profesionales en el desarrollo de aplicaciones web.

Claro, a muchos les vendrá a la cabeza patrones tales como el antiguo y denostado Cobol, y esperarán que Java se convierta en la siguiente plataforma en quedarse anticuada, pero lo que creo que falta como elemento de reflexión es la naturaleza “abierta” de la plataforma, que le permitirá continuamente adaptarse a nuevos escenarios que aparezcan dentro del panorama tecnológico.

Con esto no quiero decir que Grails no me parezca una solución válida, de hecho me lo parece, y animo a la gente a usarlo, pero si me hablan de un escenario a medio-largo plazo, creo que Java se posicionará ofreciendo lo mismo que ofrece Grails actualmente y produciéndose el dilema de si tiene  sentido continuar con  una tecnología como Grails. De momento, mi propuesta personal es “Carpe Diem”.

Federico Caro es un consultor senior con más de 10 años en el desarrollo de aplicaciones/sistemas basados en tecnología J2EE. Su carrera profesional en J2EE comenzó en Peoplecall una empresa dedicada a servicios de telefonía IP, colaborando en el desarrollo de la migración del site de PHP a J2EE integrando los servicios de facturación. Posteriormente ha pasado por departamentos de definición de arquitecturas J2EE en Indra Sistemas, Ralia Technologies (Grupo Damm) e IT-Deusto.

Ver toda la actividad de Federico Caro

Recibe más artículos como este

Recibirás un email por cada nuevo artículo.. Acepto los términos legales

3 comentarios

  1. josem dice:

    Hola, buen artículo.

    Coincido en la mayoría de puntos que expones, menos en que a día de hoy Spring Roo y Grails obtienen un empate técnico. He desarrollado aplicaciones en las dos plataformas y la diferencia de productividad la considero significativa. Definitivamente ahora mismo apuesto por Grails sin duda.

    A Spring Roo le quedan los años que ya lleva Grails en desarrollo a mi manera de ver.

    Estoy de acuerdo en que Java se ha sabido adaptar siempre a las nuevas necesidades, pero siempre ha ido un paso por detrás, como en este caso.

    No dudo que Roo siga mejorando y de aquí a un tiempo consiga lo mismo que hace Grails con “sólo” Java…

    En lo de la plataforma Java en cuanto al lenguaje y Groovy SDK para Java soy cauto viendo cómo está llevando las cosas Oracle…

    Saludos!!

  2. Genial artículo, buen desarrollo, explicación del panorama y conclusión. Pero mi opinión personal es que el empate técnico viene dado en lo que a creación, arranque y puesta en marcha de los proyectos. Aquí, ambas herramientas evitan teclear mucho boiler-plate: en el caso de Groo, te lo genera (de una manera bastante cuidada e inocua que lo hace muy atractivo) y en el caso de Grails lo procesa y te lo inyecta dinámicamente (beans e hibernate principalmente). Pero a la hora de empezar a programar, el simple hecho de tener que usar Java ya va a implicar un mayor tiempo de desarrollo, pues el código que vas a tener que teclear como programador para hacer la lógica de negocio y vistas es sensiblemente mayor; y es aquí donde Grails gana productividad desde el primer día. Incluso usando Java desde Grails, es posible usar Gorm y el resto de cosas que ofrece de serie.

    Yo creo que Groo es la alternativa ideal a Grails, cuando por cualquier razón no puedes usar Grails, pero no es rival de momento. Como bien dices, Fede, “carpe diem”, porque… quién sabe, lo mismo en 2 años Groo crece de tal manera que es posible programar igual de rápido o más que con Grails… en ese caso no tendré más remedio que reconocer que Groo ha ganado, pero de momento me lo reservo.

  3. martin dice:

    No he probado Roo. Tiene buena pinta.

    Coincido con josem en que Grails gana en madurez. Coincido en el que el soporte de Groovy/Grails en IDES es muy lamentable.

    No coincido en lo de la depuración. Realmente no veo que ninguno gane al otro en ese aspecto, ya que puedes depurar remotamente en ambos (para mi la depuración local ha dejado de ser relevante). Y tampoco coincido en el rendimiento. En micro-benchmarks sí, en aplicaciones reales la diferencia es despreciable.

    Un saludo y buen artículo!

Escribe un comentario