Java EE versus Spring: retomando a discussão

De tempo em tempo surgem artigos que retomam a velha disputa entre Spring e Java EE (algumas vezes mais focado em EJBs). O artigo mais recente é do polêmico Bill Burke que já cutucou várias vezes, dando suas razões para justificar sua visão na qual o Spring morrerá e o Java EE ganhará a batalha.

Uma das principais promessas do Java EE, como uma série de padrões definindos em especificações, as JSRs, é de dar liberdade em relação a fabricante (o vendor lock-in). Sua empresa teria então a possibilidade de escolher a melhor implementação (pelo critério de desempenho, documentação, suporte, extensões, etc.) sem ficar dependente de um único fabricante. Ao mesmo tempo, essas especificações nem sempre aparecem na velocidade desejada pelo mercado, a exemplo do Hibernate, que demorou mais de 6 anos até possuir uma especificação e aderir a ela, a JPA.

O Spring, por sua vez, apesar de ser opensource, é mantido pelo SpringSource. Ele não segue um padrão como Java EE e só participa esporadicamente nas especificações. Tudo depende da vontade do SpringSource, e claro, do mercado e dos clientes do Spring. Ao mesmo tempo, pode evoluir com maior velocidade, sem precisar esperar a criação de especificações e nem aderir a elas. O desentendimento entre SpringSource e principalmente os desenvolvedores do JBoss já começou no Hibernate e aparece até dentro da documentação do JBoss Seam, ambos iniciados pelo não menos polêmico Gavin King.

Sucesso do Spring e a ameaça ao antigo J2EE

O Spring com Hibernate dentro de um servlet container se tornou uma frequente alternativa ao EJB e a outras especificações antigas do Java EE, época que ainda se usava o acrônimo J2EE, já morto e enterrado. Mais leve, flexível e embutível desde do inicio, baseando-se em POJOs seguindo convenções, deixando configurações obsoletas, com muita injeção de dependências e baixo acoplamento para não interferir na testabilidade. Diversos conceitos e recursos que o J2EE não aplicava e não possuia na época.


Apesar de um container EJB oferecer muito mais serviços por padrão, o Spring é bastante flexível e sabe se integrar muito bem, inclusive pode ser utilizado dentro de  um servidor Java EE: pouco esforço é necessário para criar uma infra-estrutura parecida com a dos antigos EJBs. A burocracia e a complexidade dos antigos EJBs, combinadas com um ambiente pesado e uma série de más práticas, fizeram muitas empresas e desenvolvedores se afastarem do padrão.

Uma dos argumentos do Bill Burke é que Spring nunca foi uma alternativa por completo, pois sempre dependia de uma parte do Java EE. Isso é verdade, enfatizando talvez uma das principais missões do Spring: não competetir com boas soluções do mercado. Sem dúvida existem especificações maduras dentro do Java EE, como JPA, JTA ou JSF. Spring pretende oferecer soluções próprias apenas quando não há uma boa alternativa. Exemplos disso são Spring Security (alternativa poderosa ao JAAS), Spring MVC (ausência de uma especificação MVC Action-based), Spring WebFlow ou Spring Integration (lightweight messaging). Há, claro, exceções, com o Spring Web Services, que nunca conseguiu emplacar bem, sendo um dos motivos o sucesso e facilidade do JAX-WS.

CDI e Java EE 6: uma grande mudança

O sucesso do Spring pressionou enormemente o Java EE (JCP em geral) que primeiro respondeu com o EJB 3.0 introduzindo mudanças radicais como o uso da JPA em vez dos Entity Beans CMP, mas isso não foi suficiente. Java EE 6 foi outra resposta com várias atualizações como JSF 2.0, EJB 3.1, Bean Validation e CDI. Muitas dessas especificações foram inspiradas no sucesso do JBoss Seam, trazendo anotações, convenções e descomplicações que faltavam a plataforma há muito tempo. A nova especificação CDI trouxe um modelo de componentes mais leve se comparado ao EJB, e até mesmo ao Spring, e usando funcionalidades atuais da linguagem Java como anotações e generics. CDI é a cola que faltou para juntar as especificações dentro do Java EE, atacando diretamente o terreno do Spring IoC. Os EJBs perderam espaço no mercado, mas o Java EE em geral volta a ganhar força trazendo mais produtividade e cada vez mais possibilidades de utilizar cada tecnologia separadamente, ou agrupá-las facilmente através do CDI.

CDI significa o fim do Spring?

Sem dúvida CDI tapou vários buracos dentro Java EE. Ficou muito mais simples, além disso, há novos servidores disponíveis, flexíveis e leves. Muitos dos argumentos a favor do Spring não existem mais, além de que, por ter sido originalmente concebido para trabalhar com as configurações via XML, as anotações não se aplicam de maneira tão fácil e sucinta como com o CDI. Utilizando as especificações Java EE você recebe uma plataforma bastante completa para resolver muitos problemas, sem aquele risco antigo de overengineering. Lembrando que você pode (e deve!) utilizar apenas as que se enquadram na sua aplicação.

Mas nossas ferramentas estão em constante transformação. Existem novos desafios como NoSQL e cloud:  tópicos que o Java EE (ainda) não cobre. Nesse terreno o Spring continua se destacando sendo um diferencial, e claro, continua fazendo um bom trabalho na integração de frameworks e bibliotecas.

Qual será o caminho do Java EE?

No primeiro semestre de 2013 deve sair o Java EE 7  focando na nuvem e com mais simplificações, atualizando várias especificações, por exemplo JMS 2.0, JAX-RS 2.0 ou uma nova JSON API. O JCP acelerou e renovou depois do apagão da Sun mesmo após ter enfrentado dificuldades com a comunidade. Há ainda pontos sem muitas respostas: qual é a alternativa action based no Java EE? O JSF, mesmo com os esforços recentes, fica a desejar para trabalhar com websites dado os desafios atuais em relação a tamanho de dados trafegados, fine tuning de html e javascript e a apresentação mobile. Os desenvolvedores acabam aplicando JSF em pontos duvidosos, gerando páginas com megabytes de html e javascript que impactam negativamente qualquer site web. O Spring MVC aparece como alternativa e ganha adeptos. JAX-RS + CDI pode ser uma resposta, mas ainda há bastante a evoluir.

E você? Qual plataforma adotará nos seus próximos projetos? Para qual caminho acredita que elas estejam andando?

42 Comentários

  1. Flavio Sakamura 27/03/2012 at 15:56 #

    Bem lembrado: o Spring MVC ainda é um bom diferencial, ainda prefiro o action based, e ainda posso utilizar JPA com ele! Essa disputa ainda vai longe, mas o CDI foi uma boa sacada do pessoal do seam!!!!!

  2. Rafael Steil 27/03/2012 at 21:30 #

    O maior problema do Java é o JCP.. as coisas andam TÃO devagar, e são TÃO mal implementadas que precisam de diversos releases para chegar em algo usável.

  3. Eric Torti 27/03/2012 at 23:34 #

    Belo post, Nico e Flávio!

    Valeu!

  4. Deivid Martins 27/03/2012 at 23:36 #

    Até que enfim uma discussão sobre o assunto que não foi xiita para nenhum dos lados.
    Vocês deveriam publicar esse post no blog da caelumobjects também.

  5. Sérgio Lopes 28/03/2012 at 02:41 #

    O Arun Gupta postou um apanhado geral das críticas que se tem feito ao Spring nos últimos dias, citando o Bill Burke e vários outros:

    https://blogs.oracle.com/arungupta/entry/why_java_ee_6_is

  6. Lucas Pérez 28/03/2012 at 08:04 #

    Excelente Post Nico e Flávio! Parabéns!!!

    Acho que essa discussão ainda irá bem longe e creio que cabe a nós que “fazemos” o mercado refletirmos e ir achando os melhores caminhos em cada projeto.

    A bala de prata ainda não existe e essas reflexões são sempre válidas e creio que devam ser feitas em cada projeto.

  7. Luca Bastos 28/03/2012 at 08:11 #

    Dei Like no artigo e queria dar Like também no comentário do Rafael Steil que explica bem porque o Java não teria sobrevivido até hoje se não fosse por coisas feitas fora da Sun e da patotinha “chapa branca”

  8. Renan Reis 28/03/2012 at 09:46 #

    Like no comentário do Steil

  9. Rodrigo Coacci 28/03/2012 at 09:54 #

    Sério, um cara (Bill Burke) que não sabe a diferença entre testes unitários e testes de integração e diz que mocks são uma péssima idéia não merece minha atenção.
    Sugiro que leiam os comentários no artigo dele. Ele não consegue responder a nenhum comentário com argumentos sérios e consistentes.

  10. Raphael 28/03/2012 at 09:58 #

    Impressionante como vcs conseguiram abordar sobre um assunto polêmico sendo tão imparcial!

    parabens!

  11. neilson 28/03/2012 at 10:13 #

    Excelente post! Muito obrigado.

  12. Paulo Moura 28/03/2012 at 10:19 #

    É sempre bom ler artigos neste nível. Parabéns.

  13. Marcio 28/03/2012 at 11:18 #

    Bem legal o texto. Na minha opinião o Spring não “morre” tão cedo. Pelo que parece o JEE embora tenha melhorado bastante como citado no artigo, precisa de algo forte correndo a seu lado para que possa evoluir.
    É mais ou menos como se falava sobre os Japoneses nos anos 70 e 80, eles não inventavam nada, mas melhoravam tudo que já tinha sido inventado. Acho que o JEE nesse caso, pode vir a ser os Japoneses.

  14. Isaque Xavier 28/03/2012 at 11:53 #

    Muito legal o post, parabens,

  15. Henrique Guimarães 28/03/2012 at 13:06 #

    Excelente post!

  16. nei 28/03/2012 at 15:06 #

    Desculpa a ignorância, mas pq o JSF não é considerada a solução action based no Java EE?

  17. Nico Steppat 28/03/2012 at 15:39 #

    @nei A discussão component-based vs action-based vai longe, mas explicando bem por cima:

    JSF é um framework MVC component-based. São os componentes que tentam esconder a complexidade no desenvolvimento web. Você não precisa conhecer HTML ou JavaScript (e Ajax) ou saber detalhes sobre o protocolo HTTP. É parecido com o desenvolvimento desktop mas para web.

    Os frameworks action-based, ao contrário, não tentam esconder a “natureza” do protocolo HTTP, só simplificam o uso. O desenvolvedor continua no controle do HTML e JavaScript. Isso significa que, além de ser mais trabalhoso, é preciso ter o conhecimento dessas tecnologias, mas também vai ter uma flexibilidade maior no dia-a-dia. Spring MVC e VRaptor são exemplos de frameworks action-based.

  18. Diogo Souza 28/03/2012 at 18:04 #

    O Bill Burk sempre foi o que diria “excêntrico”, apesar do cara de fato se garantir…

    Muito bom o post! Parabéns!

  19. Luiz Roberto 28/03/2012 at 23:09 #

    Arun Gupta é pago pra evangelizar o JEE 6 no mundão, e
    Bill Burke um contributor do JBoss, cujos posts não foram nada imparciais.

    Por esse motivo, parabéns pela imparcialidade do post!!!

    No fim, a comunidade sempre dita o caminho!!

  20. Willian F. Batista 29/03/2012 at 00:27 #

    Realmente a discussão vai longe, contudo recentemente a empresa em que trabalho optou por usar o Spring para novos projetos, isso depois que algumas experiências não tão boas com JBoss Seam 2.0 e JSF na criação de formulários complexos.

    Atualmente usando Spring IoC, MCV, Data JPA ( a propósito excelente), Security e algumas outras facilidades que o spring oferece, estamos muito satisfeitos com os resultados.

    O único ponto que deixa um pouco a desejar são as jsps. Que não favorecem na criação do conceito de “masterpage” mesmo usando frameworks como Sitemesh ou Tiles, neste ponto os resultados poderiam ser melhores.

  21. Everton Tavares 29/03/2012 at 09:14 #

    Quando você diz no artigo que o JSF deixa a desejar com WebSites, você inclui sistemas Web? Ou se refere a websites como uol, globo, terra, etc…?

  22. nei 29/03/2012 at 09:28 #

    Respondido!! Obrigado pela explicação Nico 😉

  23. Nico Steppat 29/03/2012 at 11:00 #

    @Everton: Me referi aos Web Site apenas e não Web Apps (ou sistemas web, como vc falou).

  24. Rafael Duque Estrada 05/04/2012 at 14:06 #

    @Willian F. Batista

    Sitemesh ou Tiles? Para que?

    Solução:
    http://stackoverflow.com/questions/1296235/jsp-tricks-to-make-templating-easier

  25. Fábio Arezi 24/05/2012 at 10:20 #

    não acho que o JEE6 não tenha solução pra action based. Se for ver, o servlet 3.0 com anotações + jsp+jstl quebra um baita galho pra fazer sites. Claro que se for algo mais complexo, temos o tupiniquim VRaptor. Mas pra sistemas web (principalmente internos) eu acho o JSF imbativel 🙂

  26. Julio Cesar Cabral 25/05/2012 at 14:42 #

    Ainda bem que o pessoal da Caelum sabe que existem muitos ótimos recursos no framework Spring e ele não trata apenas sobre DI. CDI nem isso consegue fazer direito. Quero ver CDI atender web flow sem escrever código para isso. Além disso, a especifcação para JPA no caso de Criteria é horrorosa. Fato é que Spring traz simplicidade e velocidade de desenvolvimento e o Spring MVC 3 está demais, além dos outros maravilhos recursos que o Spring oferece.

  27. Raul 11/06/2012 at 16:05 #

    É notável a quantidade de gente que argumenta a favor do JCP, sobre o fato dele ir agregando soluções de outras tecnologias com o tempo.

    Porém o Spring faz isto também, com melhor qualidade, mais recursos e disponibiliza com uma velocidade muito maior ao JCP. E vai muito além, com o grande nicho inovador deles, como foi bem mencionado no ótimo artigo.

  28. Hermano Soares 23/08/2012 at 13:40 #

    Belo, artigo!
    Mas minha aposta continua sendo Spring !

  29. Henrique Lobo Weissmann 26/12/2012 at 10:15 #

    Interessante este post.
    Mas sabe, toda esta discussão sobre Spring vs Java EE não é lá grande coisa por um fato muito simples: o Spring não foi criado para ser um substituto ao Java EE, mas sim um complemento a este. Então é importante que a gente consiga separar bem as coisas.

    Bom, após ter estudado alguma coisa sobre o assunto, acho que posso dar o meu pitaco aqui. 🙂

    * Spring sempre vai ser vanguarda se comparado com o Java EE desenvolvido pelo JCP. Lembrem-se: o JCP é um comitê, e portanto sempre vai ser bem mais lento e, pior ainda, na esmagadora maioria das vezes, sempre vai optar pelo menor denominador comum, ou seja, features presentes no Spring podem não estar presentes tão cedo no Java EE.

    * Questão do XML: virou mito desde que o Spring incluiu suporte a anotações (se não me engano, na versão 2.0). Aliás, no Spring 3.0 você sequer precisa do arquivo de configuração mais. Então, não é mais lá tanto problema assim.

    * Questão da “leveza”: importante lembrar que lightweight não quer dizer leve no carregamento, mas sim a minimização das dependências do seu código fonte com relação ao framework. Neste sentido, os dois se igualariam, pois o Spring também trabalha com as anotações do Java EE e, em teoria, seu POJO funcionaria tão bem no container do Spring quanto no Java EE.

    * Mais sobre leveza: infelizmente, leveza máxima só é obtida por configuração externa, ou seja, XML, que te possibilita, por exemplo, não usar anotação alguma caso queira. Yeap: esta é a vantagem do XML: você consegue externalizar sua configuração sem a necessidade de recompilar seu código, ao contrário das anotações que ainda não são externalizáveis.

    * Fator desktop: em desuso mas não acabado, ainda há muitas aplicações desenvolvidas para o ambiente desktop nas quais o Spring é aplicado e com muito sucesso. Neste ponto, Spring vence, porque você pode trazer aspectos do Java EE, por exemplo, sem a necessidade do servidor Java EE completo.

    * AOP: o suporte a AOP do Spring ainda é superior ao do Java EE, apesar de que, este gap deve se igualar daqui a algum tempo. Porém, de novo, é a questão do comitê versus projeto livre né? Sempre o Spring vai estar na frente neste ponto.

    * Vendor lock in: se você for pegar a filosofia por trás do Spring que é ser o mais lightweight possível, você não tem vendor lock in: você tem POJOs que poderiam ser reaproveitados em qualquer ponto. Neste sentido, você não teria este problema, mas isto sempre depende mais de quem está entre a cadeira e o teclado né? 🙂

    No final, é aquela questão: cada caso é um. Se seu projeto se adequa mais ao Java EE convencional, vai pra ele. Caso contrário, sempre vai haver o Spring e outros containers de IoC/DI pra você brincar.

  30. Realidade 10/02/2013 at 10:15 #

    A OracleSun vive correndo atrás dos outros. JSF é ilusão que só atrapalha no final das contas. Só pelo SpringMVC Spring já ganha.

  31. Jonas Brolesi 20/11/2014 at 11:02 #

    Artigo excelente, esclarecedor e simples. Facilmente podemos entender quando devemos utilizar Spring ou J2EE. Na empresa que trabalho atualmente utilizamos Spring MVC e J2EE, juntos. Confesso que nunca tinha visto as duas tecnologias trabalhando juntas. O resultado é uma grande performance.

  32. Diego Lirio 25/11/2014 at 01:36 #

    Muito bom…

  33. Fabio Henrique 26/11/2014 at 15:11 #

    Um Arquiteto J2EE jamais recomendaria o Spring como um substituto… cada um no seu quadrado.

  34. Aurélio 20/04/2015 at 17:43 #

    Eu comecei a estudar e utilizar o Spring há 8 meses. O controle de transações é algo muito bom, algo que o framework realmente nos fornece. Não conheço muito bem alguns recursos vindos no CDI mas acredito que não exista um suporte a transações como no Spring.
    Outro ponto importante que ainda está amadurecendo no Mundo do Spring é o Spring Data, eu o achei espetacular, a produtividade aumenta muito, claro que considerando o desempenho temos que analisar melhor, mas é um recurso muito útil fornecido pelo framework e não vejo discussão sobre recursos desse tipo na JCP.
    Mas o “MVC 1.0” está chegando e vamos ver no que vai dar, espero que tenhamos mais tópicos a discutir em breve.

  35. Paulo Sergio 22/09/2015 at 16:01 #

    Muito boa sua explicação Henrique Lobo mesmo vc sendo suspeito em falar de Spring hehehe.

    Spring realmente te da varias vantagens “Facilidades”.

    Parabens

  36. cviniciusm 03/12/2015 at 08:09 #

    No artigo “How not to hate Spring in 2016” (http://spring.io/blog/2015/11/29/how-not-to-hate-spring-in-2016) é citado “No seu coração, Spring é um framework de integração. Ele provê um modelo de programação consistente através de muitas tecnologias diferentes” . E cita como é difícil manter essa integração. De um lado, Spring Framework fornece os ingredientes e o Spring Boot é o bolo pronto. Assim, percebe-se claramente o movimento de independência do Spring. De outro lado, o Java EE suprindo suas deficiências ao longo do tempo (que antes supridas pelo Spring). Portanto na minha opinião, para 2016 em diante, escolha um (Java EE ou Spring) e seja vencedor 😉

Deixe uma resposta