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”.