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](PaaS: http://java.net/downloads/javaee-spec/PaaS.pdf) 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?