flozano.com: Haz commit, maldito!

Cuando un post en theserverside.com obtiene más de 100 comentarios, quiere decir que algo pasa. O se han enganchado los de JBoss a discutir con los de Spring, o la comunidad se ha puesto a rajar viva al visionario de Tapestry, o cosas así. Todos estos asuntos no suelen acabar teniendo la mayor trascendencia, pero éste último sí que la puede tener, en mi opinión:

http://www.theserverside.com/news/thread.tss?thread_id=50727

Esta vez es algo que nos afecta a muchos de los que apostamos en su momento por una estrategia de desarrollo más sensata, sencilla, fácil, testable e integrada, y nos decidimos a usar Spring.

Para quién no lo conozca, Spring es un framework con cuatro áreas funcionales bien separadas en mi opinión:

• Proveer un Contenedor IoC (Inversión de Control), para hacer desarrollos más testables y menos acoplados, y aumentar la cohesión del código. No interfiere en el código de la aplicación
• Proporcionar funcionalidad transversal no de negocio, tal como transaccionabilidad, “tuberías”, mensajería, remoting… No interfiere en el código de la aplicación, normalmente (puede hacerlo).
  
• Proporcionar clases base, templates y herramientas para facilitar el uso de tecnologías Java comunes (JMS, JDBC, JCA…) Sí interfiere en el código de la aplicación
• Proporcionar frameworks completamente dedicados, como el Spring MVC. Obviamente, sí interfieren en el código de la aplicación.

Spring es modular y uno puede elegir si usa uno u otro módulo sin problemas… lo que ocurre es que cuando uno decide usar uno, es más fácil que se acabe usando otro y otro… haciendo de Spring al final una pieza fundamental en la aplicación.

Lo que ha ocurrido para revolucinar tanto a la comunidad de desarrolladores y arquitectos es que la empresa propietaria de SpringSource (antes interface21) ha publicado una nueva política de liberación de versiones, que restringe a los usuarios sin contratos de mantenimiento el acceso a los parches incrementales de las versiones no “current” a únicamente tres meses.

Es decir,pongamos que yo uso Spring 2.0.2 en una aplicación que lleva N meses en producción, y la versión actual es Spring 2.5(.1), desde hace más de tres meses. En esto, me aparece un “bug” en la aplicación debido a un fallo en Spring 2.0.2. Me dispongo a arreglarlo, pero al no tener contrato de mantenimiento no tengo acceso a la versión corregida 2.0.3, sino que tendría que actualizarme a Spring 2.5.2. Obviamente, si tengo esta aplicación en producción, me hará muy poca gracia cambiar de versión “major” del framework sobre el que he desarrollado mi aplicación.

Los “mantenimientos” tienen sentido en algunas cosas… pero en el framework de inversión de control de tu aplicación? es rizar el rizo… y qué hay de las aplicaciones que usan spring y tienen su propio modelo de licencias? ahora debes incluir también a spring en el stack a licenciar y mantener por el cliente (oracle + sistema operativo + cluster + servidor de aplicaciones + mi aplicación + el framework de inversión de control) ? No se si es muy lógico…

Imagino que interface21 está intentando “capitalizar” la ubiquidad de su framework y rentabilizar la inversión (enorme) que ha hecho en  él, pero no sé si es la mejor manera. Ahora, muchos de los que usabamos Spring extensivamente, y que lo hemos hecho tan popular, vamos a pensarnoslo muy mucho antes de volver a elegir la pastilla roja y volver creer en una empresa que hasta ahora había sido un bálsamo para la comunidad de desarrolladores Java. Spring seguirá teniendo una calidad técnica excelente y una cantidad enorme de seguidores, pero esto va a allanar el camino a otros frameworks, como los EJB 3.X estándar, Seam, o Guice.

Yo voy a ser conservador, y si tengo que acometer nuevos desarrollos en Java seguiré confiando en Spring, pero lo haré como se debe hacer: sin casarme con él, utilizando sus funcionalidades transversales y “de contenedor”, pero sin permitir que contamine mi código; o si lo permito, me preocuparé de encapsularlo bien y acotarlo defensivamente para que aparezcan “imports” de org.springframework sólo en sitios concretos.

Lo hare así porque las alternativas no están al nivel adecuado, en mi opinión. Con EJB 3 tienes mucho pero no “todo”… EJB 3.1, cuando venga, será una gran mejora e igual sí permite plantearse confiar únicamente en estándares (ya veremos)… Seam aporta mucho (los scopes conversacionales son una gran idea) pero no me convence del todo su modelo, y además, al usarlo, uno se casa con él más que con Spring… y por último Google Guice es demasiado sencillo, no tiene todo lo que uno necesita, “contaminas” el código con montones de imports para las anotaciones y además tiene carencias importantes en el modelo de componentes basado en clases en vez de en objetos con “id” o “nombre”.

En fin, veremos como se suceden los acontecimientos