Category Archives: Spring Framework

Falando de Spring 4.0 na Java Magazine 130

Acaba de sair a edição 130 da Java Magazine na qual há um artigo que escrevi sobre as novidades do Spring 4.0. Nele falo sobre a evolução do framework e detalho alguns aspectos desta nova versão como, por exemplo, o suporte a WebSocket,  Spring Boot (em ambos os casos mostro exemplos rápidos de uso das tecnologias), Groovy e mais alguns aspectos.

Detalhes do artigo podem ser vistos neste link. Meu próximo artigo será sobre Spring Boot, até lá!

O que muda no Spring 4.0?

thumb_beta_spring_largeComo 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

groovylogo

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!

wslogo

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

spring-boot-project-logo

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

Semana Groovy #8

Links da semana

Como cai no Groovy e mergulhei no Grails: descrevo o início da minha trajetória com Groovy e a origem do Grails Brasil – http://www.itexto.net/devkico/?p=1907

10 tecnologias que empolgam desenvolvedores. Groovy e Gradle no topo! –  http://zeroturnaround.com/rebellabs/10-kick-ass-technologies-modern-developers-love/

Introdução ao Spring XD (Extreme Data), que tem como base Spring e Grails – http://www.infoq.com/articles/introducing-spring-xd

Groovy Weekly #31 – http://glaforge.appspot.com/article/groovy-weekly-31

Apresentações

Usando Groovy para escrever aplicações Android! A famosa apresentação que foi mencionada na primeira edição da semana Groovy agora está disponível! – https://www.youtube.com/watch?v=AebkFsfcuDg

Teste funcionalmente seus projetos Grails com GEB –  https://www.youtube.com/watch?v=McFoNTKD8Q0

CRaSH the shell for the Java Virtual Machine – um projeto interessantíssimo para aqueles que desejam um melhor monitoramento de seus projetos é o CRaSH. Basicamente ele nos fornece um shell no estilo SSH que nos possibilita inspecionar remotamente o funcionamento dos nossos sistemas e ainda executar algumas tarefas. Esta apresentação é um verdadeiro chamado para que todos nós passemos a usar esta tecnologia. :) – https://www.youtube.com/watch?v=ZRQwZfP2uIc

Entrevista com Juergen Hoeller sobre Spring 4, Java 8 e Spring XD – Juergen Hoeller foi um dos fundadores do projeto Spring. Interessante ouvir se você se interessa pelo futuro destas tecnologias – http://www.infoq.com/interviews/Juergen-Hoeller-QConNY-2014-Interview

Lançamentos

Groovy 2.3.5 – Diversas correções de bugs. Uma novidade desta versão é que se preocuparam com compatibilidade com versões futuras, pois incluiram um artefato chamado groovy-backports-compat23 (leia o post no blog do Guillaume Laforge a respeito: http://glaforge.appspot.com/article/groovy-2-3-5-out-with-upward-compatibility ). Vale à pena ler o release notes aqui: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10242&version=20491. Em seguida, faça o download em http://www.groovy-lang.org/download.html

Spring 4.1 RC – Uma novidade interessante é o fato de que agora o Spring MVC vai ter suporte nativo a templates Groovy!  – http://spring.io/blog/2014/07/21/spring-framework-4-1-release-candidate-available

Projeto da semana

GR8 CRM – O objetivo do projeto é fornecer funcionalidades de CRM (Customer Relationship Management) para aplicações Grails. Consiste em um amontoado de plugins. Estes irão trazer funcionalidades como gestão de contatos, gerência de tarefas e de projetos, notas, etc. Sem sombra de dúvidas é bastante interessante e vale à pena navegar pelos plugins: http://gr8crm.github.io/

Posts clássicos

Guia itexto: o container de injeção de dependências do Spring – Por baixo do Grails há o Spring Framework. É muito importante que o desenvolvedor entenda os conceitos por trás do Spring para tirar máximo proveito do Grails. Neste artigo (que acabou dando origem ao meu livro sobre o mesmo assunto) todos estes conceitos são explicados em detalhe – http://www.itexto.net/devkico/?p=859

GORM por trás dos panos. GORM é o framework de persistência do Grails. Já faz algum tempo que passou a ser uma API independente também. O melhor lugar para entender seu funcionamento por trás dos panos é o guia para desenvolvedores do framework,que pode ser acessado neste link: http://projects.spring.io/grails-data-mapping/manual/index.html

Assine nossa newsletter!

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

Modularizando JavaScript com Spring MVC e Jawr

javascript-logoEste post inicia uma série na qual vou expor técnicas que visam aumentar a manutenibilidade de código Javascript. Convenhamos: é uma linguagem de programação legal, porém muitas vezes o hype que a envolve nos impede de ver seus aspectos negativos. Neste post tratarei de uma das cicatrizes da linguagem que é a dificuldade que enfrentamos na modularização do código.

O problema: modularizar JavaScript usando Spring MVC

Se você tem a sorte de trabalhar com Grails tem à sua disposição uma solução maravilhosa que é o plugin resources que nos permite definir “módulos Javascript”. Infelizmente do lado Spring da cerca não temos algo tão popular. O que é um módulo Javascript?

Uma unidade de código que funciona em conjunto.

Muitas vezes esta unidade não é apenas um arquivo, mas vários, e é neste ponto que o problema começa a se manifestar. Imagine um módulo composto por dois arquivos: biblioteca.jsbiblioteca2.js. Sua equipe pode ter achado interessante dividi-lo em dois arquivos para paralelizar o esforço e com isto evitar todos aqueles incômodos relacionados ao merge de arquivos. Nesta situação, toda vez que você precisa usar este módulo, irá inserir em suas páginas código similar ao exposto a seguir:


<script type="text/javascript" src="/resources/js/biblioteca.js"></script>
<script type="text/javascript" src="/resources/js/biblioteca2.js"></script>

Ou então você poderia ter algum script que unisse os dois arquivos. O problema é que seria necessário modificar o seu processo de build e também fornecer garantias de que o arquivo gerado fosse sempre o mais atualizado possível (não é uma solução tãão bacana assim).

Agora, voltemos ao nosso exemplo. Imagine que este nosso módulo dependa do jQuery. Neste caso teríamos sempre de escrever o seguinte código em nossas páginas:


<!-- jQuery sempre irá ser carregado primeiro -->
<script type="text/javascript" src="/resources/js/jQuery.js"></script>
<script type="text/javascript" src="/resources/js/biblioteca.js"></script>
</span><script type="text/javascript" src="/resources/js/biblioteca2.js"></script>

Ainda pior: imagine que a ordem de carregamento dos arquivos biblioteca.jsbiblioteca2.js seja importante. Agora sua equipe precisa ser informada a respeito. Se for uma aplicação de uma única página, não será lá um grande problema, mas imagine uma aplicação maior, com mais de um template, etc. A coisa começa a se complicar.

A imagem a seguir expõe bem a situação do nosso projeto. Temos uma biblioteca composta por dois arquivos que depende de uma terceira:

jawr_dependencias

Não seria bacana se houvesse uma ferramenta que nos permitisse resolver os problemas a seguir de uma forma simples?

  • Documentar as dependências entre os nossos arquivos Javascript de tal forma que seja fácil para a equipe entender a organização interna do projeto.
  • Garantir que os arquivos sejam sempre carregados na ordem correta.
  • De alguma maneira otimizar o modo como estes arquivos são enviados ao browser: compressão via gzip, talvez até mesmo um merge dos arquivos.

Jawr entra em cena

logoJawr

Jawr é uma ferramenta que tem como objetivo resolver os três problemas que expus acima e mais alguns. Neste post irei tratar de uma parte bem pequena deste projeto: aquela que lida com Javascript. A grosso modo Jawr é um servlet que iremos inserir em nosso projeto fictício. Este servlet organizará nossos módulos Javascript em bundles.

O que é um bundle? É um módulo, tal como expus acima. Mais do que isto, um bundle alguns atributos fundamentais do nosso módulo:

  • Que arquivos compõem o nosso módulo
  • Em que ordem estes arquivos devem ser carregados
  • Quais as dependências do nosso bundle, isto é, que código este precisa para funcionar?

Voltando ao nosso projeto percebe-se que há dois bundles: biblioteca e jQuery, que podemos representar gráficamente tal como na imagem a seguir:

Nossos bundles

Nossos bundles

Poderíamos pensar em um bundle único composto pelos nossos arquivos da biblioteca e o do jQuery. O problema é que sabemos que jQuery será usado por diversos outros pontos da nossa aplicação: sendo assim é interessante que modularizemos esta parte a fim de que seja reaproveitada em outras partes do projeto.

Incluindo Jawr em nosso projeto

Nosso projeto é baseado em Maven. Sendo assim, para incluirmos o Jawr basta adicionar a dependência no arquivo pom.xml tal como no exemplo a seguir:

<dependency>
    <groupId>net.jawr</groupId>
    <artifactId>jawr</artifactId>
    <version>3.3.3</version>
</dependency>

Como disse logo acima, Jawr é essencialmente um servlet. Sendo assim temos também de alterar o arquivo web.xml para que fique similar ao exposto a seguir:

<!-- Servlet para lidar com Javascript -->
<servlet>
   <servlet-name>JavascriptServlet</servlet-name>
   <servlet-class>net.jawr.web.servlet.JawrServlet</servlet-class>

		<!-- Aonde se encontra o arquivo de configuracao -->
   <init-param>
       <param-name>configLocation</param-name>
       <param-value>/jawrJavascript.properties</param-value>
   </init-param>
   <init-param>
       <param-name>mapping</param-name>
       <param-value>/bundle/js/</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
</servlet>
<!-- O mapeamento de URL -->	
<servlet-mapping>
   <servlet-name>JavascriptServlet</servlet-name>
   <url-pattern>/bundle/js/*</url-pattern>
</servlet-mapping>

Preste muita atenção no mapeamento de URL. Na documentação oficial do Jawr este é configurado para que lide com todos os recursos que terminem com a extensão .js. O problema com esta abordagem é que muitas vezes não queremos que todos os nossos arquivos Javascript sejam carregados como bundles. Talvez você queira ir adotando aos poucos a ferramenta em seu projeto (esta é a principal razão que vejo). Em nosso caso, Jawr só irá lidar com aqueles recursos Javascript que se encontrem na url /bundle/js/*. Nota importante: repare no parametro de inicialização mapping. Se for usar uma configuração como esta, este obrigatóriamente deve estar definido.

Configurando os bundles

No mapeamento do servlet foi incluído um parâmetro chamado configLocation. Em nosso projeto baseado em Maven este arquivo se encontra em /src/main/resources/jawrJavascript.properties. É neste arquivo que iremos definir todos os nossos bundles. Abaixo está um exemplo deste arquivo:

# Altere aqui caso esteja no seu ambiente de desenvolvimento
jawr.debug.on=false

# Devemos enviar os bundles compactados?
jawr.gzip.on=true

# De quantos em quantos segundos o servlet deve verificar se as configuracoes foram
# alteradas. Extreammente util em tempo de desenvolvimento!
jawr.config.reload.interval=30

# Primeiro bundle de exemplo: jQuery
# O identificador do bundle sempre é o que aparece antes do ‘.id’
# neste caso, é jquery
jawr.js.bundle.jquery.id=/bundle/js/jQuery.js
jawr.js.bundle.jquery.mappings=/resources/js/jquery-2.1.0.min.js

# Incluindo uma dependencia
jawr.js.bundle.biblioteca.id=/bundle/js/biblioteca.js
jawr.js.bundle.biblioteca.mappings=/resources/js/biblioteca.js, /resources/js/biblioteca2.js
jawr.js.bundle.biblioteca.dependencies=jquery

Um bundle Javascript é definido no arquivo com o prefixo jawr.js.bundle.[identificador do bundle]. A primeira linha, que termina com .id define como será a URL que define o nosso bundle. O bundle jQuery, por exemplo, sempre será carregado quando a URL /bundle/js/jQuery.js for acionada, enquanto o bundle biblioteca, pela URL /bundle/js/biblioteca.js.

Voltemos nossa atenção para o bundle biblioteca. A segunda linha da sua definição (mappings), define quais os arquivos que o compõe e a ordem na qual devem ser carregados. A terceira linha define quais as suas dependências. Neste caso, apenas uma: o bundle jquery.

Tendo feito isto temos todos os bundles em nosso projeto prontos para serem usados. O próximo passo é trabalhar no arquivo JSP.

Alterando o arquivo JSP

O projeto Jawr vem com uma biblioteca de tags bastante útil. Abaixo podemos ver um exemplo de sua aplicação:

<%– A declaração da biblioteca de tags –%>
<%@ taglib uri="http://jawr.net/tags" prefix="jwr" %>

<%– Carregando o bundle biblioteca –%>
<jwr:script src="/bundle/js/biblioteca.js"/>

E o que ocorre quando carrego a página? Obtenho o resultado a seguir:

<script type="text/javascript" src="/itexto/bundle/js/gzip_N1063700552/bundle/js/jQuery.js" ></script>
<script type="text/javascript" src="/itexto/bundle/js/gzip_N745101183/bundle/js/biblioteca.js" ></script>

Primeiro será inserida a dependência do bundle biblioteca e, em seguida, o código fonte do bundle biblioteca. Repare nas URLs: o Jawr irá automáticamente cachear os recursos Javascript. E sabem o que é mais legal? Ele também envia o Javascript comprimido (se o modo de depuração estiver desativado (veja as notas no arquivo que expus acima)). E não é só o conteúdo Javascript comprimido. Os dois arquivos que compõem o módulo biblioteca também são mesclados em um só, diminuindo assim o número de requisições necessárias. Simples assim. :)

Concluindo

Nese post apresentei uma pequena parte do projeto Jawr. Há mais neste servlet, que também pode ser usado para gerenciar recursos CSS e imagens. É importante salienar que a documentação do projeto é excelente: bem escrita e fácil de ser consultada.

Claro que a questão da modularização não termina aqui. Esta é apenas uma das soluções possíveis. Recentemente topei com um ebook online (e gratuito) chamado Writing Modular JavaScript with AMD, CommonJS & ES Harmony que trata da questão de uma forma muito mais profunda. Entra aí também o modo como escrevemos JavaScript (que não tratei neste post) e alguns outros pontos sobre os quais pretendo escrever mais a respeito em um futuro próximo.

O código fonte deste post pode ser acessado no meu GitHub: https://github.com/loboweissmann/jawr-testes

Vire o Jogo com Spring na coleção Frameworks Java da Casa do Código!

fwj-thumb-large_large_large

Hoje recebi uma notícia muito bacana do pessoal da Casa do Código:  meu livro “Vire o Jogo com Spring Framework” está agora incluído na coleção “Frameworks Java” da editora!

É uma promoção bem bacana: você compra três livros: “Aplicações Java para web com JSF e JPA”,  “Vire o Jogo com Spring Framework” e “VRaptor” com 15% de desconto, ou seja, sai por R$ 74,90.

E ah… também pra contar um negócio massa oficialmente. Já estou com o meu próximo livro em andamento. Sim: Groovy e Grails, de uma forma bem diferente do que você poderia imaginar. Mais novidades em breve. :)