Java EE 7 vs Spring Framework es una de las comparativas que cada día empezaremos a ver mas. En muchas ocasiones he escuchado que Spring Framework va a morir y que los standards se van a imponer, ya que realizan todas las tareas que realiza Spring Framework. Lo sorprendente es que esto ya lo escuché cuando llego Java EE 5 y cuando llego Java EE 6 y seguimos igual. ¿Porque esto no acaba de pasar?.
Standards y Extensibilidad
Cuando utilizamos los standards como por ejemplo los Ejb tenemos la ventaja de que nuestro servidor de aplicaciones nos aporta todo lo que necesitamos. Sin embargo no tenemos una gran capacidad para extenderlo y añadir nuevas funcionalidades que consideremos necesarias. El servidor de aplicaciones nos provee de todo para lo bueno y para lo malo.
Spring Framework y puntos de extensibilidad
Spring Framework funciona de una forma muy distinta a los Standards e incluye muchos puntos de conectividad/extensibilidad que permite que muchos otros frameworks se acoplen a él.
Así pues según vayan apareciendo nuevos frameworks y nuevas soluciones Java, Spring a través ya sea de programación Aspectual, de uso de patrones como template y factory o de listeners facilitará a los nuevos frameworks su integración.
El futuro
Por mucho que los standards sigan avanzando, la innovación y los nuevos frameworks seguirán apareciendo en el mercado. Una parte importante de los desarrolladores seguirá teniendo la necesidad de integrar estos productos antes de que los standards los incluyan dentro de su soporte y es aquí donde Spring tiene mucho que decir. Por lo tanto seguiremos viviendo con una dualidad entre estos dos productos, Spring y los Standards que se repartirán una gran parte del mercado.
En mi opinión spring va un paso por delante de Java EE, pero el objetivo de Java EE es recoger y estandarizar las mejores prácticas/mejores frameworks, es evidente que irá un paso por detrás porque ese es el objetivo. Mi experiencia personal después de trabajar con los 2 es que Spring tiene todo, demasiadas cosas, acaba siendo un monstruo en proyectos grabdes. Aunque también se agradece la rapidez con las que sacan cosas nuevas (somos programadores, nos gusta probar cosas nuevas, no?). Por otro lado ahora estoy en un proyecto con tomEE y la verdad es que estoy muy cómodo.… Read more »
Creo que TomEE , es un proyecto genial.
[…] Otros artículos relacionados : ¿Es el fin de los servidores Java EE? , Java EE vs Spring […]
Si utilizas ADF dejarás Spring. ADF realiza las tareas repetitivas. Vamos, todos sabemos q insert,, upate, PreparedStaarement, Mybatis, etc son mapeos y tipeos meramente repetitivos, ejemplo: ResultSet, insert tableA bla bla bla, update tableB bla bla bla, o sea lo que cambia es la base de datos, y después el crud acomoda(mapea) estos datos via programador usando DAO, o usando Hibernate, o usando arrays, o usando Spring…bien ¿por qué tienes que invertir tiempo en mapear lo que cambia en base de datos? no es más inteligente que exista un framework que mapee esos DAOs y que inviertas tiempo y esfuerzo… Read more »
Spring Data hace algo similar 🙂
Es muy valido tu punto de vista desde el tema de acceso a datos y front end, pero dependiendo del negocio, el problema es el framework en temas de front end ya que son componentes y me parece que los componentes gui son rigidos en temas de formato, es decir que para hacer un mejor componente hay que invertir tiempo y aprender la filosofia. Tambien esos componentes hace que pierdas las tendencias de diseño (aunque hay prime faces y todos eso) Entonces Ganas agilidad con una parte pero puedes perder por otra. Spring Mvc es orientado a acciones y el… Read more »
Yo entendería que ya es un tema cultural de la empresa y de gustos, hace tiempo atrás se peleaba que el futuro era struts, ahora se pelea que el futuro es Spring, pero como se indicó arriba en otro comentario, todo termina siendo java, pero ciertamente es un tema largo para discutir. También depende de tu plataforma de trabajo, un simple tomcat? Un pool de weblogic o en nuestro caso varios websphere, la lógica de negocio esta en tu capa de la aplicación o en la BD manejados por un kernel y varios SP Ciertamente hay muchas cosas que se… Read more »
Yo creo que cada día es más cultural.
Pregunta de un examen: “Participas en un proyecto y en tu empresa dudan entre utilizar frameworks conocidos (Struts, Spring y Hibernate) o utilizar la última versión de Java EE. Explica qué conceptos y tecnologías de dichos frameworks ya están incorporados en Java EE y cuáles no.”
¿Cuál es la respuesta?
Gracias
Todas están incluidas en Java EE , Struts y el modelo MVC están en Java EE , quizás haya que esperar a Java EE 8 para tener un framework puro … pero el patrón MVC esta incluido. Los principios de Inyeccion de dependencia y programación Aspectual de Spring están en Java EE. La persistencia de Hibernate la aporta JPA
[…] Otros artículos relacionados: ¿Tiene futuro JSF? , Java EE vs Spring Framework […]
Hola Cecilio, he visto su trabajo, realmente pienso que es una persona con sólidos conocimientos en Java. Necesito hacer una pagina de reclutamiento en la web, es mas que una pagina es un sistema web como tal. En estos momentos me encuentro en busca de la tecnología a utilizar de java ee, para lo que se refiere a la seguridad, capa de presentación y los demás componentes que se requieren.
Muchas gracias por su apoyo.
Yo optaría por Spring MVC + Spring Security + JPA casi seguro ya que aunque no es lo más moderno es la mas robusto y extensible.
Desde el punto de vista del coste de formación de un equipo de desarrollo que desconozca por completo tanto Spring como EJB, IoC, DI, etc. ¿qué solución consideráis que tiene una curva de aprendizaje más rápida?
GRACIAS
Depende mucho de que mundo partan de conocimiento parten de .NET , parten de PHP ?
JavaEE no es testeable. Los descriptores estan clavados a sus sitios, el descubrimiento de contexto está basado en classpath lo que no permite hacer pruebas unitarias. El desarrollo típico es 10x veces mas lento de lo normal por tener que de usar el ciclo escribir-empaquetar-desplegar-probar. Las herramientas como Arquillian o JRebel mejoran un poco la situación, pero son demasiado artificiales y lentas. La única forma de poder desarrollar y proyecto real con JEE es usar por debajo el mismo Spring. Consejo para los que estan obligados desarrollador en JEE. Hay un proyecto Apache OpenEJB — el único contenedor que se… Read more »
gracias por tu punto de vista 🙂
Que buen chiste.
Buscando artículos y comparativas sobre el uso de Spring y JEE, he encontrado este blog y de casualidad el libro, el cual, empezaré a leer ahora mismo. En mi experiencia, por cultura de empresa, en aplicaciones críticas y que requieren un alto rendimiento y tener absolutamente todo bajo control (ante un error, ser capaces de corregirlo de forma inmediata) no permitimos el uso de Spring, de ningún framework de terceros que no controlemos totalmente. Para aplicaciones de CRUD o sistemas de información / consulta, utilizamos Spring y cualquier otro framework que nos permita agilidad en los desarrollos. De todas formas,… Read more »
No hay soluciones totales para nadie ,cada casuística requiere su analisis
Larga vida a spring!!!
yo creo que sí que tendrá larga vida 🙂
Spring siempre ha estado por delante de las especificaciones JEE , atendiendo y simplificando el desarrollo, al permitir una evolución mucho mas rápida que el estándar de turno. Últimamente vemos como las diferentes versiones de JEE van incorporando todas esas funcionalidades y ventajas que incorpora principalmente spring y otros middleware o frameworks. Sin embargo java nunca aportará esa flexibilidad y rapidez para la evolución que aporta spring y cuando en un proyecto integras spring, limitas el uso del JEE a aquellas funcionalidades y especificaciones que más te gustan o que mas cómoda te resultan de utilizar (y es completamente correcto.)… Read more »
“Sin embargo java nunca aportará esa flexibilidad y rapidez para la evolución que aporta spring” Aunque es cierto que Spring va por delante de Java EE en algunos temas como en el manejo de las transacciones, decir que Spring va por delante de Java es absurdo. Spring está hecho en Java. Si Spring llega de visita a Nueva York, Java va con él. Sólo queria aclarar eso, porque una cosa es Java y otra Java EE. Java EE es la versión limitada de Java que se encarga de hacerlo más “empresarial”: – Nada de threads. – Nada de sockets. –… Read more »
Desde mi punto de vista, si tiene sentido decir que Spring va por delante. Spring lógicamente está hecho en Java, al igual que Java EE, que también está hecho de Java.
Y entiendo que cuando se dice que va por delante es porque las ideas en las que se basa Spring, son las que años después adopta Java EE.
Yo creo que cada día es más claro que es así 😉
Este tema está para tomar un café y charlar varias horas…en mi opinión es complicado que Spring desaparezca, pues es un framework cuya bondad mayor es la integración entre distintas tecnologías, cosa que no tengo bastante claro que el estándar JEE 7 pueda cumplir…me pondré las pilas para investigar bondades que Spring tenga sobre JEE7 y con gusto se las compartiré…Saludos!
muchas gracias 🙂
Es imposible que Spring desaparezca, ya que es open source. Las empresas basadas en código cerrado pueden desaparecer, quebrar, ser compradas y sus productos eliminados, etc., pero cómo eliminas el código open source? Tendría que salir un producto open source mejor y éste reemplazar al antiguo, hasta que el antiguo sea olvidado. Java EE siempre ha tenido el problema de que es dificil hacer tests unitarios. De hecho siempre me encuentro con gente que me dice “fácil, pones SOAP UI y listo”, eso es como …. “estamos en 2016 y hay gente que aún no sabe qué son los tests… Read more »
Para gustos los colores esta claro 🙂
Vengo del futuro y ya estamos en Spring 5 saludos
que cierto es 🙂
Desde mi punto de vista y el escenario real de un proyecto donde se imponen los costes y la agenda la decisión sobre JEE vs Spring ha de basarse en la experiencia de tu equipo de desarrollo.
Esto sería desde el punto de vista práctico.
Desde el punto de vista de la teoría me inclinaria por JEE7 frente a Spring por su no propietaridad.
Muchas gracias Cecilio por tu blog y tus libros.
Saludos
Gracias . Estoy muy de acuerdo contigo que cada día es mas una decisión “cultural” a nivel de la empresa.
Me parece que lo que aquí se dice no concuerda con la realidad.
Hasta hace un tiempo y por los problemas que conlleva J2EE. Spring fue una buena alternativa.
Hoy por hoy JEE es bastante más ligero.
Con experiencia les digo que usar Spring y su famosa modularidad.
Al final y a medida que tu proyecto va creciendo y se siente la necesidad de ir implementando más librerías del ecosistema Spring. Terminas teniendo una aplicación súper pesada……
Ah y con respecto a CDI no ha nacido por Spring IOC sino por WELD de Jboss….
Gracias por el aporte … esta claro que tu has decidido dejar Spring y apostar por Java EE de forma fuerte… cuales son las ventajas mas claras que le has visto? 🙂 gracias
Yo no he usado Spring, pero creo que JEE tiene un soporte muy sólido por parte de las muchas empresas que forman la comunidad JCP. Ese respaldo y las pruebas que hacen son suficientemente confiables. En Spring es una única empresa privada la que ha de hacer las pruebas y cambios. Parece que con JEE8 va a haber un estándar MVC. Veremos.
Pues si , yo creo que seguirán compitiendo ambas 🙂
Creo que nace de spring sin embargo su implementacion de referencia es weld como lo comentas
Esto es cierto. Ahora bien, JEE es un comité de expertos. Spring es el hijo de Rod Johnson, uno de los expertos del comité y que fue eliminado del comité porque no estuvo de acuerdo con EJB… ya sabemos porqué… y terminó creando Spring para demostrar que tenía razón. Copiaron la idea dentro de JEE y JEE quedó mucho mejor, no les quedaba otra, sino Spring se los comía. Es cierto que JEE quedó mejor que Spring, especialmente en el tiempo de startup y en evitar tanto enredo con tanta dependencia de la inyección de depedencias. Pero todavía Spring tiene… Read more »
muy cierto 😉
Yo veo claro el papel de cada uno en el mundo Java:
Spring -> Marca el ritmo de la innovación
Java EE -> Marca los estándares bebiendo directamente del resto de actores.
Batch es Spring Batch adaptado
MVC es Spring MVC adaptado
CDI es el Spring core IOC
etc
Si yo creo que Spring sigue siendo el que marca el ritmo.