Como escrevi um livro sobre o Spring Framework, não é raro que eu receba perguntas pelas redes sociais a respeito da versão 4.0. Meu livro ainda trata da versão 3.2, então aquilo que disse nele ainda é válido? Resposta rápida: em 100% dos casos, sim.
As mudanças superficiais no Spring são raras: se seu projeto é baseado na versão 3.2 do framework, a migração para o 4.0 é muito tranquila. Só é necessário alterar as dependências do seu projeto para a nova versão na esmagadora maioria das vezes. Neste post irei falar sobre as mudanças que considero serem as mais importantes.
(não sabe o que é o Spring Framework? Eu tenho um guia gratuito que pode te ajudar. Clique aqui!)
Pivotal entra em cena
Este é o primeiro grande release do Spring sob a supervisão da Pivotal. Se havia receio a respeito da competência desta nova empresa, este se transformou em alegria, pois o trabalho que fizeram foi simplesmente fantástico!
Um dos principais objetivos da empresa foi melhorar a experiência de início de projeto com o Spring, então reformularam completamente o site oficial (http://www.spring.io) . As mudanças vão muito além do layout: incluíram uma série de guias que ajudam os desenvolvedores a iniciarem da maneira mais rápida possível seus projetos baseados tanto no Spring como também nas tecnologias baseadas neste framework.
Os guias são muito diretos: fáceis de ler e sem rodeios. Precisa implementar um servidor REST? Quer usar o GORM? Quer começar algo? É enorme a possibilidade de haver um guia pronto para que você possa por a mão na massa rápido. Vale muito à pena conferir os guias: http://spring.io/guides. Além disto em cada subprojeto há um guia que te mostra o básico da tecnologia em questão.
Rejuvenescendo o Spring
Classes, métodos e pacotes marcados como obsoletos
Conforme o tempo passa todo projeto começa a sofrer com seu código legado. O pessoal da Pivotal então tomou uma decisão corajosa: marcou como obsoletas diversas classes, métodos e pacotes que compunham o código fonte do Spring. Você pode ver a lista completa neste link. Se seu projeto usa classes internas do framework (o que é uma péssima prática em qualquer framework), então algumas classes vão ter de ser substituídas em sua aplicação (você foi avisado!).
Do 3.2 para o 4.0 seu projeto funcionará perfeitamente, mas a partir da versão 4.1 é bem provável que diversas destas classes não venham mais com o framework. Em um primeiro momento soa desagradável esta remoção em massa, mas na prática é vital para garantir a longevidade do projeto. Menos código legado leva a um custo menor de manutenção e possibilita um foco maior na inclusão de recursos realmente importantes para o desenvolvimento de novos projetos e para atender necessidades que estão surgindo.
Olhando para a frente: suporte total ao Java 8, Java EE 6 e 7
O Spring 4.0 foi lançado antes do Java 8 e já vinha com suporte total à nova versão da linguagem. Um ponto importante é que agora a versão mínima do Java é a 6.0: natural dado que o Java 5 já tem 10 anos (saiu em 2004). Você já pode tirar proveito de recursos como lambdas, referências a métodos, suporte total à nova API de tempo (java.time).
Do lado Java EE é importante mencionar que agora a versão mínima da especificação será a seis. Muitas dependências de terceiros (3rd party dependences) também sofreram com isto. A partir da versão 4.0 do Spring estas devem ter sido desenvolvidas a partir de 2010. Exemplos interessantes: Hibernate 3.6+, EhCache 2.1+ e Groovy 1.8+.
O objetivo disto tudo é claro: estas medidas nos deram mais uns vinte anos de Spring (no mínimo) pois o custo de manutenção de tecnologias legadas daqui pra frente foi significativamente reduzido.
Groovy cada vez mais presente
Este é um ponto que muito me alegra: Groovy está muito mais presente no Spring 4.0. Nós que programamos em Grails já usamos a linguagem para declarar nossos beans (nos raríssimos casos em que isto é necessário) desde a versão 0.x do framework. É uma DSL bastante prática mas que até então estava disponível apenas para desenvolvedores Grails.
Agora qualquer um pode usar esta DSL: você não precisa mais do Grails para declarar seus beans em Groovy. È possível fazer isto em projetos Java de forma bastante tranquila graças à inclusão da Groovy Bean Definition Language.
Aqui faço uma aposta: a Pivotal percebe o valor do Grails. Prevejo cada vez mais recursos do Grails aparecerem no core do Spring Framework. Na versão 4.1 já está inclusive previsto o suporte a templates Groovy no Spring MVC.
Mudanças no container de injeção de dependências e inversão de controle
Foram incluídos alguns novos recursos que considero bastante interessantes. O primeiro deles diz respeito à anotação @Lazy. Até a versão 3.2 do framework nós apenas a aplicávamos na definição de beans, fazendo com que estes só fossem iniciados quando necessários. Agora ela vai além: podemos aplicá-la também em pontos de injeção!
A outra mudança interessante é que agora podemos usar generics como qualificadores de nossos beans. Abaixo está um exemplo que copiei direto da documentação oficial para ilustrar o seu uso:
@Autowired private Store<String> storeString; @Autowired private Store<Integer> storeInteger;
Em algumas raras situações é bastante prático.
Spring MVC com suporte a WebSocket!
Uma adição que justifica o upgrade. Agora o Spring oferece suporte nativo à tecnologia WebSocket e, claro: da maneira Spring, ou seja, é fácil de usar! Mais do que isto, eles também oferecem suporte a SockJS, que é uma tecnologia de fallback que permite simular websockets em navegadores mais antigos.
E o melhor deixei pro fim: Spring Boot
O Spring Boot não é um componente do Spring, mas sim um projeto independente. A idéia é tornar a criação de projetos baseados em Spring muito mais ágil, fácil, desburocratizada, leve e foda. E eles conseguem.
O foco principal por trás da versão 4.0 é tornar o desenvolvimento com Spring ainda mais rápido. O Boot nos possibilita isto ao trazer para o framework o conceito de “convenção sobre configuração”. Na documentação oficial do projeto você verá diversas vezes “opinionated view”, mas no fundo o que querem dizer é “convenção sobre configuração” (COC).
O que é COC: para a maior parte das suas tarefas, a configuração é essencialmente a mesma. Então por que obrigar o programador a se repetir? O Boot trás uma série de configurações pré-prontas para você: se precisar de algo mais customizado, basta sobrescrevê-las. Diversos requisitos não funcionais já vêm pré-configurados no Boot, e isto irá te poupar muito tempo.
Mais do que isto, o Spring Boot facilita o desenvolvimento de micro serviços (já escrevi sobre esta arquitetura aqui e aqui) e muda bastante a visão que temos sobre o desenvolvimento Java EE. Pra começar, o servidor é embarcado por default, então você executa sua aplicação com o comando java -jar (também é possível gerar um war se você quiser).
E o tempo que você leva para iniciar um projeto Spring Boot? Apenas o de copiar e colar os trechos de código Maven presentes no site do projeto no seu arquivo pom.xml. E sabem de outra coisa? Este será o único XML que você usará em seu projeto (e já era assim na versão 3.2). Um dos objetivos do boot é acabar com o mito de que gastamos muito tempo com arquivos XML no Spring.
Infelizmente este post é pequeno demais para que eu possa falar mais a respeito do Boot. MInha sugestão é que você passeie pelo site oficial do projeto primeiro.
(sem exagero: na minha opinião este projeto muda radicalmente nossa visão sobre desenvolvimento de aplicações corporativas na plataforma Java)
Concluindo
Apesar das mudanças, o Spring 4.0 ainda é usado exatamente como estamos acostumados na versão 3.x. Há novos recursos, como a DSL em Groovy para declarar beans, mas tirando isto, tudo o que lhes falei no livro ainda é válido e não precisa ser alterado (se leu o livro e encontrou pontos que precisam ser alterados, entre em contato comigo, ok?).
O que fica claro lendo a documentação e diversos posts na Internet é que a Pivotal conseguiu rejuvenescer o Spring: e muito! Quando escrevi o livro muita gente não via vantagem em usar o framework dados os avanços do Java EE 7. Hoje com certeza o Spring está de novo na vanguarda: mais leve, tão simples como antes e surgindo projetos cada vez mais interessantes como o Spring Boot, Spring Data, Spring XD e tantos outros.
Estas foram as novidades do Spring 4 que mais me chamaram a atenção. E sabem o que acho mais bonito? Exatamente pelo fato do projeto sempre ter ser baseado apenas nos conceitos de Inversão de Controle, Injeção de Dependências e AOP permitiram que este evoluísse sem que com isto seus usuários necessitassem reaprender o framework em sua nova versão.
O framework evoluiu, mas você que conhece os conceitos (e torço para que tenha lido meu livro :)) não ficou obsoleto com isto: apenas ganhou alguns novos brinquedos para aplicar em seus projetos. ;)
PS:
já está planejada a atualização do “Vire o Jogo com Spring”. Se você comprou pela Casa do Código, receberá atualizações automaticamente. Então dá pra comprar agora e garantir sua atualização em um futuro bem próximo. :)
Deixe uma resposta