No puedo ser indiferente con SpringSource

SpringSource compro G2One, lo cual es un evento suficientemente significativo para mover la blogsphere JEE y llenar foros de conversación.

Las distintas opiniones que aparecieron en esta entrada en TheServerSide  me permiten hacer como un checklist de los temas que ya toque en mi blog y poder compararlo con lo que opinan los miembros de TSS.  

Primero tengo que mencionar que TSS sigue un lugar para peleas entre representantes/fanáticos de jBoss y SpringSource.  En esta oportunidad, Rod Johnson se quedo callado y es Bill Burke de jBoss que fue al ataque.  Pero Spring tiene suficientes fanáticos para evitar que el guro tenga que intervenir.

Ahora, voy tema por tema.

Lightweight vs Heavyweight  

Bill Burke ataco a Spring por ser heavyweight, pero tuvo la mala idea de justificarlo solamente por el tamaño (80 MB) de los binarios de Spring.  Una de las respuestas razonables fue que la pesadez debe medirse con el impacto sobre el diseño de la aplicación.  

"lightweight has nothing to do with the dependency size, rather at how it impacts your application's design and its constraints."

Yo sigo opinando que la pesadez es un termino ambiguo que puede/debe medirse de varias formas:

• estoy de acuerdo con Bill, el tamaña si importa 
• si el contenedor tiene que cargar 80 MB de clases además de la webapp, la partida se va a ver afectada,
• IBM Rational Developper pesa 3.5 GB.  Netbeans con Glassfish pesa 200 MB, es tremenda diferencia para mi ADSL banda estrecha.

• estoy también de acuerdo con Bill, que Spring ahora es heavyweight porque trata de solucionar todo y es funcionalmente tan amplio como los contenedores JEE que lo precedieron.  Eso impacta por ejemplo, el aprendizaje necesario para conocer cada uno de los "Spring-*" y compararlo con otra solución: yo ya he abandonado esta tarea y me quedo con Google Guice por ser liviano y limitado en su alcance (DI y nada más que DI).

Los frameworks de DI son un accidente transitorio 

Nuevos lenguajes como Scala y Groovy los hacen menos relevantes:

"I've been waiting for people to realize that a good, concise dynamic language that provides clean integration with Java largely obviates the need for DI containers and/or allows for much more powerful approaches to DI containers. "

El uso de anotaciones en JEE 5 alivia el desarrollo y reduce la importancia de framework DI.

"Now what is Spring's contrbution to the platform..um... lets see... 

1. A wrapper which is possibly useless with JEE6"

"I love SpringSource's products, but I find them much less needed today than five years ago. RIP, my love! "

Ataques constantes a SUN 

La noticia no tiene nada que ver con SUN pero igual salio al baile:

"Have you been sleeping? Sun is lost in the weeds looking for an OSS strategy...Who better to run with the torch than Spring?"

De nuevo, aparece el tema OpenSource y encuentro increíble que ataquen a Sun por eso.  Antes de cambiarse a OpenSource, la suite Java de SUN estaba completamente inutilizable y moribunda.  Ahora, quizás SUN no gana directamente con su suite de software pero, por lo menos tiene una completa y competidora con IBM, Microsoft, Oracle, Red-Hat, Google.  Es algo estrategico para enfrentar el mercado de "cloud-computing" que viene.  Por otra parte, Solaris esta bien posicionado para aprovechar la explosión del multi-core, lo que dudo que Linux haga con tanta facilidad.

Existe también la preocupación constante por el estado financiero de SUN, la cual comparto a 100%.  De hecho, si los productos no fuesen OSS, no los recomendaría: hay un riesgo no menor que SUN sea comprado por otra empresa y que cambie radicalmente el futuro de sus software.  El hecho que sean OSS los protege de este punto de vista.

Rol de Rod Johnson y SpringSource en la estandarización de Java

Algunos prefieren que SpringSource sea el líder de la estandarización de Java.  Menos mal que hubieron respuestas bastante claras como por ejemplo:

"The idea of Spring taking stewardship of Java is crazy talk. Looking after Java requires theoreticians (e.g. Gilad), compiler experts, Swing and graphics experts, lots of maintainers and bureaucracy and much, much more. i.e. you need deep pockets and an iron stomach for these things"

"Say what you want about JBoss, but at least we've shared our IP with the Java community by bringing both Hibernate and Seam to a standards body. Then, if our business practices offend you for some reason, you can always move to another implementation. You can't say the same thing about Spring."

"That's a good point. SpringSource doesn't seem to be sharing Spring in JCP in a direct fashion that JBoss has with Hibernate(JPA) and Seam(Web Beans). "

En resumen:

• SpringSource es una mosca en comparación de SUN y se necesita espalda para cumplir este rol.
• El aporte de SpringSource a la estandarización ha sido casi nula hasta ahora.
• jBoss ha aportado mucho más que SpringSource al proceso de estandarización: JPA (Hibernate), WebBeans (Seam).

Finalmente, Bill Burke acusa a Rod Johnson, el cual es miembro reciente del JCP, de bloquear avances significativos de la plataforma.

"...this is exactly how Rod positions himself in the EE JSR and pretty much fights against any forward movement of the platform. "

Si se confirma este tipo de acusación, pasare Rod Johnson de anti-héroe a super villano.

Evolución de los framework MVC

La compra de G2One confirma la tendencia de usar lenguajes más concisos para la capa web en lugar de un framework Java.

Opino lo mismo, pero creo que no debe limitarse a la capa de presentación y Groovy tiene, a mi gusto, sus limites en otras capas.  También, opino que la cercanía a Java como la que tiene Groovy y Scala son factores importantes para la adopción.

En resumen, fui una buena entrada en TSS.  Polémica quizás, pero entretenida.