Atenção: esse artigo tem um vídeo complementar. Clique e assista!

A melhoria contínua é uma prática constante que os desenvolvedores do Spring têm seguido desde o início da construção do framework. A cada versão lançada, novidades para facilitar o uso de APIs, frameworks e bibliotecas mais utilizados pelo mercado (como o JPA, JMS, Hibernate, entre outros) têm sido adicionadas. A nova versão não é exceção, novas classes que facilitam o uso de web services e a integração de sistemas foram incorporadas. Elas serão detalhadas nos próximos tópicos com alguns exemplos.

No entanto, a melhoria extrapolou as bibliotecas, também foram feitas mudanças para auxiliar na configuração do framework. Até a versão antiga do Java era difícil encontrar mecanismos que unissem flexibilidade e simplicidade para configurar um framework que não fossem o uso de XML. Com as modificações do Java 5, foi aberto um precedente para criar alternativas ao XML para facilitar a configuração do framework, deixando de ser “apenas” produtivo e também se tornar simples.

O artigo irá demonstrar, na prática, como as mudanças na forma de configuração do Spring e as novas bibliotecas podem auxiliar todos os desenvolvedores a criar um código de melhor qualidade e empregando as principais tecnologias utilizadas pelo mercado Java EE.

Quais os objetivos das mudanças e novidades?

Por oferecer uma maneira transparente de integrar os frameworks mais usados pelo mercado (ex.: JSF, Hibernate e Struts) através de configurações e classes de apoio, o Spring tem atraído muitos programadores que procuram facilitar o desenvolvimento de aplicações corporativas.

Contudo, com a evolução das aplicações corporativas, observou-se que o arquivo de configuração e os códigos fonte cresciam de maneira assustadora. Por causa disso, alguns programadores acreditavam que o problema era do Spring, no entanto, numa análise mais detalhada feita pelos desenvolvedores do Framework, notou-se que a causa deste crescimento estava relacionada com a sintaxe simples, porém limitada, da versão da linguagem Java que era utilizada.

Como forma de se redimir desta falsa impressão, os desenvolvedores do Spring resolveram adotar as sintaxes mais recentes da linguagem, que possibilitam um código mais enxuto e de maior produtividade.

Aumento de produtividade

Os programadores normalmente focam suas atenções no desenvolvimento do código fonte. Entretanto, para que o código funcione, é necessário configurá-lo, como acontece com os EJBs e Servlets. Por padrão, essa configuração era feita através de arquivos XML. O problema é que alterar tanto o código como a configuração exige uma maior atenção do programador, devido à necessidade de realizar as configurações em dois lugares. Infelizmente, essa era única maneira que existia para criar códigos desacoplados e, por isso, foi o modelo adotado nas primeiras versões do Spring.

Entretanto, com o surgimento das anotações no Java 5, essa separação de configuração e código desapareceu, unificando no código fonte as informações de configuração. Assim, o programador não precisa mais atualizar o arquivo de configuração e o código fonte, aumentando sua produtividade.

Experiências na própria plataforma Java EE (como a Java Persistence API e EJBs 3.x) demonstraram o ganho de produtividade e simplificação, comparando com as tecnologias equivalentes nas versões mais antigas da plataforma. Observando este fato, os criadores do Spring resolveram adicionar ao framework o uso de anotações, com o objetivo de unificar a configuração e codificação, e ter os mesmos ganhos alcançados na Java EE.

Adaptação às novidades sintáticas da linguagem

O código fonte do Spring foi atualizado para utilizar as melhorias da sintaxe do Java, como varargs e Generics. No entanto, diferente do que muitos imaginam, essas alterações não acarretam problemas para o código baseado nas versões antigas do Framework.

Os leitores do Javadoc perceberão que as construções de código ficaram mais simples, e, portanto, mais fáceis de serem mantidos e lidos. Podemos citar como exemplo a diminuição no número de arrays criados para passar parâmetros (substituído pelo uso de varargs), e a retirada de operações de cast (devido à adoção de Generics).

Inovações

Para completar, algumas inovações foram introduzidas para ajudar nas configurações de ambiente, que eram desconhecidas até o momento da implantação e que exigiam mudanças no código fonte. A Spring Expression Language (uma linguagem de sintaxe similar à Unified Expression Language do Java) tem o intuito de oferecer uma forma de usar bibliotecas Java através de uma sintaxe mais simples e sem a dependência de um compilador. Desta forma, para alterar um projeto basta modificar o arquivo de configuração colocando código Java, usando-se de construções simplificadas, como a criação de objetos e chamadas de métodos.

Além disto, o aumento no número de classes para facilitar a integração de sistemas é um destaque entre as novidades. Um paradigma que tem ganhado espaço no Java é a Arquitetura Orientada a Serviços (SOA), baseado no uso intensivo de XML. Para facilitar a leitura de XML pelos sistemas, diversas bibliotecas que traduzem o XML para um objeto foram criadas, como JAXB e JiXB. Entretanto, estas bibliotecas possuem modelagens distintas, como nomes de classes e interfaces diferentes.

Observando que cada uma possui suas peculiaridades (principalmente relacionadas à performance) mas com o mesmo objetivo, os desenvolvedores do Spring resolveram criar um conjunto de classes que permitem trocar as bibliotecas sem modificar os códigos existentes. Isso permite ao desenvolvedor alterar um código baseado, por exemplo, em JAXB, por outro que se utiliza das bibliotecas alternativas modificando a configuração, como veremos adiante.

Outra tendência de mercado é o uso de formas mais enxutas para troca de dados entre sistemas, sem o overhead existente no modelo de web services, empregando o protocolo HTTP, denominado REST. O Spring resolveu criar classes que simplificam a troca de informações com serviços REST.

Quais são as mudanças?

Frameworks evoluem com o passar do tempo e muitas vezes exigem mudanças que o adequem às necessidades dos desenvolvedores. Nesta versão, as alterações foram tão profundas que exigiram dos criadores do Spring uma reavaliação de conceitos, que culminaram numa reestruturação organizacional do Framework e na adição de novas técnicas para sua configuração.

Estrutura do framework

O Spring nasceu para resolver os problemas de integração mais cotidianos que existiam na época de sua concepção. Isso envolvia acesso a dados provenientes de banco de dados ou de sistemas externos (COBOL/SAP), e a apresentação destes dados aos usuários empregando tecnologias de visualização baseadas em um ambiente web. Tudo isso poderia ser integrado mediante o uso de um container de Inversão de Controle, que é o bloco desenhado na base da Figura 1.

Figura 1. Representação dos blocos constituintes do Spring nas versões 2.x.

Contudo, diferente do passado, em que as bases de dados eram usadas para integrar sistemas, novas ferramentas especializadas foram criadas, como as filas de Mensagens (Message Queues) ou web services. Em sintonia com estas novas tendências, os desenvolvedores do Spring criaram novas bibliotecas que simplificam o uso destas ferramentas.

Para indicar que são utilizados para integrar sistemas, os blocos DAO (renomeado para JDBC), ORM, o recém-separado JMS e o novo OXM foram agregados em um conjunto batizado de Integração e Acesso de Dados, como apresenta a Figura 2. Isso reitera que o framework cresceu para atender não apenas aos dados, mas também a integração de sistemas.

Figura 2. Estruturação dos pacotes do Spring após a sua reorganização.

Dos blocos adicionados na nova estrutura do Spring, um dos que mais se destaca é o Test. Ele é o resultado da reengenharia de algumas classes para testar códigos. Nas versões anteriores estas classes dependiam do Core Container para serem executadas. A partir da versão 3.0, elas também podem ser usadas em projetos desvinculados ao Spring.

Neste bloco, encontramos classes que simulam o ambiente de um servidor Java EE. Alguns exemplos são classes que simulam um servidor de nomes (JNDI) e a tradução do protocolo HTTP realizado pelo container. Tudo isso com o objetivo de testar códigos sem que o servidor de aplicação Java EE esteja ativo, permitindo uma rapidez maior na execução dos testes.

Os blocos Aspects e Instrumentation são extensões do Spring para implementar a programação orientada a aspectos seguindo os padrões definidos pela AOP Alliance e os ferramentais necessários para que os aspectos possam ser incorporados em servidores de aplicação através de instrumentação dos bytecodes.

O bloco Web continua a dar suporte a uma grande quantidade de tecnologias Java EE e frameworks proprietários, como o Struts e o WebWork. Para evitar referências de nomes com trademarks, o Spring resolveu apenas referenciar as tecnologias principais do mundo de Java EE.

Uma novidade adicionada ao Core Container é a nova API Spring Expression Language, que é uma versão “turbinada” da Unified Expression Language (Unified EL), introduzida na Java EE 5 para padronizar as EL que coexistiam em JSP e JSF.

Pelo fato da Unified EL ser simples e bastante flexível, o Spring resolveu, usando como base a especificação, criar melhorias para que a linguagem pudesse usar a sintaxe Java para customizar aplicações sem que houvesse necessidade de compilação. Essa ideia já é utilizada por alguns frameworks como JBoss Seam, que a emprega para auxiliar em algumas tarefas como a execução de testes e a amarração de objetos que precisem manter um estado conversacional.