El futuro Java EE 7 vs Spring Framework

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.

 

JavaEE7vsSpring

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.

SpringFrameworkExtensibilidad

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.

It's only fair to share...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

About Cecilio Álvarez Caules

Cecilio Álvarez Caules Sun Certified Enterprise Architech (J2EE/JEE).

41 Responses to El futuro Java EE 7 vs Spring Framework

  1. Vicente 30 Enero, 2017 at 0:16 #

    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. Más simple que con Spring, no hace falta.añadir los 500 módulos que tiene Spring. Es testeable y rápido, nada que ver con los antiguos WebLogic, WebSphere y compañia. Se echa un poco de menos versiones más frecuentes, pero bueno, a cambio tienes una base sólida y simple (lo de la portabilidad es un poco un mito, a poco que empiezas a meterte en temas avanzados quedas algo atado a la implementación)

    • Cecilio Álvarez Caules 30 Enero, 2017 at 15:01 #

      Creo que TomEE , es un proyecto genial.

  2. Paul 4 Octubre, 2016 at 1:32 #

    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 en cambiar la base de datos de acuerdo al análisis del negocio?, o sea, si te dicen: de ahora en adelante la tabla X tendrá el campo imagen, y tú dale que tipeas el JavaBean, tipeas el Store, tipeas el DAO, el prepareStamentent, el Controller, el JSON, todo lo tipeas, alli pierdes tiempo por que es tan igual tipear el campo imagen para la tabla A que tipear el campo nombre para la tablaB, o tipear x campos para x tablas, en todas pondrás update o insert o select o delete, nada nuevo, lo que vale es el cambio en base de datos. Bien, dicho framework es ADF BC, cambia el campo N de la tablaX y zas! actualizado sin tipear nada, no significa que no sepas, significa q tu esfuerzo va a cosas que no son mecánicas ni repetitivas. Y así arrastras su datacontrol y zas! tienes la tabla en JSF, y ya: ganaste tiempo, dinero y tecnología. Spring? qué es eso? se tipea? olvídate, has apps de verdad, utiliza Oracle ADF.

    • Cecilio Álvarez Caules 4 Octubre, 2016 at 8:31 #

      Spring Data hace algo similar 🙂

    • Guillerml 2 Febrero, 2017 at 15:25 #

      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 front end (puro html con thymeleaf)

      Spring Data hace el mapping de las tablas. Puedes usar spring y poner jsf en el front. Al final el objetivo es poder tener aplicaciones con bajo acoplamiento entre sus capas y poder dar responsabilidad a los aspectos ( spring aspects) de esas tareas que no pertenecen a la logica de negocio (bitacoreo, seguridad, auditoria, etc

  3. Alexander Mogollón 12 Agosto, 2016 at 20:01 #

    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 ve aplicado de manera “arcaica” como describieron arriba pero a la final todos se rigen por la regla de oro…. quien pone el oro pone las reglas (aka: los jefes)

    Yo recomendaria que cualquiera haga sus análisis a modo personal y estudie lo que mas le plazca, bien sea spring mvc o j2ee, tome su decisión y los estudie a fondo y se especialice…

    • Cecilio Álvarez Caules 13 Agosto, 2016 at 9:14 #

      Yo creo que cada día es más cultural.

  4. Eduardo 24 Mayo, 2016 at 16:16 #

    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

    • Cecilio Álvarez Caules 24 Mayo, 2016 at 20:30 #

      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

  5. Naty 2 Febrero, 2016 at 16:38 #

    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.

    • Cecilio Álvarez Caules 2 Febrero, 2016 at 18:31 #

      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.

  6. Joan Costa 1 Noviembre, 2015 at 13:35 #

    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

    • Cecilio Álvarez Caules 1 Noviembre, 2015 at 18:56 #

      Depende mucho de que mundo partan de conocimiento parten de .NET , parten de PHP ?

  7. Antón 19 Septiembre, 2015 at 13:54 #

    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 puede arrancar en modo Embedded desde la misma aplicación y que utiliza el mismo classpath del proyecto sin necesitar empaquetarlo todo en un jar. El contenedor es completamente configurable programáticamente y muy flexible en cuanto a alternación de descriptores, y recursos.

    JEE es inutil. Todas las tecnologias que ofrece contenedor estan disponibles como librerías o frameworks. El concepto de un servidor mainframe donde trabajan varias aplicaciones está caducado como 15 años. Hoy en día mas habitual que una aplicación trabaja en varios servidores. Los estandares son demasiado artificiales y abstractos y nunca cubren las necesidades reales que ocurren casi en cada proyecto.

    • Cecilio Álvarez Caules 19 Septiembre, 2015 at 14:00 #

      gracias por tu punto de vista 🙂

    • fado 26 Marzo, 2017 at 0:12 #

      Que buen chiste.

  8. David 12 Septiembre, 2015 at 11:12 #

    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, seguimos analizando con nuestro software de APM (Dynatrace), las nuevas versiones de Spring para su posible incorporación, pero de momento, este framework sigue incorporando tiempo extra, que no podemos asumir en un entorno empresarial.

    Espero haber ayudado con mis comentarios.

    • Cecilio Álvarez Caules 12 Septiembre, 2015 at 18:48 #

      No hay soluciones totales para nadie ,cada casuística requiere su analisis

  9. Martin 6 Junio, 2015 at 2:39 #

    Larga vida a spring!!!

    • Cecilio Álvarez Caules 7 Junio, 2015 at 8:52 #

      yo creo que sí que tendrá larga vida 🙂

  10. Manuel Gonzalez 14 Mayo, 2015 at 10:24 #

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

    Y solo quería aprovechar para dar mi opinión sobre varios comentarios que he visto aquí.

    El MVC es un patrón que ya se implementaba ad-hoc en cada aplicación y que Struts comenzó a estandarizar , Spring MVC y el MVC son las evoluciones naturales y lógicas de esas primeras implementaciones del patrón.

    Spring no inventó el iOC ni tampoco JBOSS , hace muchos años que ya realizábamos esas buenas practicas en aplicaciones j2ee . Spring solo normalizó y estandarizó dicha practica.

    No es necesario idealizar java y spring porque su éxito se basa en incorporar soluciones que aportamos toda la comunidad a necesidades concretas y generalizadas.

    Un saludo a todos.

    • Guillermo Schwarz 26 Febrero, 2016 at 7:56 #

      “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.
      – Nada de synchronized.
      – Nada de escribir archivos.
      – Transacciones demarcadas a través de contenedores EJB.

      • Gabi 28 Octubre, 2016 at 13:20 #

        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.

        • Cecilio Álvarez Caules 1 Noviembre, 2016 at 8:56 #

          Yo creo que cada día es más claro que es así 😉

  11. Raul Vargas 12 Mayo, 2015 at 0:17 #

    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!

    • Cecilio Álvarez Caules 12 Mayo, 2015 at 8:51 #

      muchas gracias 🙂

    • Guillermo Schwarz 26 Febrero, 2016 at 7:20 #

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

      Spring se supone que alivia eso, pero en la práctica, cuando he trabajado en un proyecto con Spring, la configuración para ejecutar los tests son sábanas de XML… te aseguro que estoy mucho mejor sin usar Spring en lo absoluto, prefiero tener factories y contexts, así puedo instanciar servicio mock y reutilizar mis tests para correr contra servicios mock y reales.. y me olvido de todas estas patrañas…

      Hay cosas buenas de Spring como Spring JDBC. Pero todo esto de la inyección de dependencias, cuando la usan hasta para lavarse los dientes… da asco… por favor usen pasta de dientes y escobilla de dientes… existen por algo… la inyección de dependencias sólo donde se necesita, el resto que se joda.

      Spring MVC parece decente, es un Struts pero un poco más limpio, sin embargo prefiero n framework MVC de verdad, como Vaadin, de lejos.

      Spring tiene muchos fanáticos que no entienden realmente cómo evaluar Spring y lo usan de manera indiscriminada

      • Cecilio Álvarez Caules 26 Febrero, 2016 at 12:45 #

        Para gustos los colores esta claro 🙂

  12. Juan Manzano 8 Mayo, 2015 at 12:52 #

    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

    • Cecilio Álvarez Caules 9 Mayo, 2015 at 8:15 #

      Gracias . Estoy muy de acuerdo contigo que cada día es mas una decisión “cultural” a nivel de la empresa.

  13. grafity 7 Mayo, 2015 at 13:15 #

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

    • Cecilio Álvarez Caules 8 Mayo, 2015 at 7:00 #

      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

      • Pedro Díaz 20 Mayo, 2016 at 0:00 #

        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.

        • Cecilio Álvarez Caules 20 Mayo, 2016 at 6:38 #

          Pues si , yo creo que seguirán compitiendo ambas 🙂

    • Paolo 26 Enero, 2016 at 12:46 #

      Creo que nace de spring sin embargo su implementacion de referencia es weld como lo comentas

    • Guillermo Schwarz 18 Febrero, 2016 at 23:31 #

      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 ventajas como no necesitar un contenedor para ejecutar.

      • Cecilio Álvarez Caules 19 Febrero, 2016 at 0:13 #

        muy cierto 😉

  14. Oscar 6 Mayo, 2015 at 11:58 #

    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

    • Cecilio Álvarez Caules 6 Mayo, 2015 at 21:11 #

      Si yo creo que Spring sigue siendo el que marca el ritmo.

Trackbacks/Pingbacks

  1. Las versiones de Java y su historia - Arquitectura Java - 7 Enero, 2017

    […] Otros artículos relacionados :  ¿Es el fin de los servidores Java EE? , Java EE vs Spring […]

  2. ¿Es el fin de los servidores Java EE? - Arquitectura Java - 1 Abril, 2016

    […] Otros artículos relacionados: ¿Tiene futuro JSF? , Java EE vs Spring Framework […]

Deja un comentario