A SpringSource anunciou o Spring 3.1 GA, a nova versão estável (General Availabitity) do Spring Framework. Essa versão do Spring inclui diversas novidades, entre elas o suporte ao Java 7; o Bean Profiles um novo conceito que permite abstrair as mudanças de configurações conforme o ambiente de execução; uma nova funcionalidade que habilita o uso de cache na chamada de métodos Java; e o suporte ao padrão Servlet 3.0. Em um artigo recente do InfoQ.com, são apresentados mais detalhes sobre as novidades do Spring 3.1.
O InfoQ conversou com Chris Beams, o committer principal no projeto Spring Framework, para saber mais sobre essa versão e quais são os planos para o Spring 3.2.
InfoQ: O Spring 3.1 GA foi inicialmente planejado para o fim de Junho. Quais são os motivos para o atraso da versão?
O plano original para essa versão era fornecer toda a configuração do container do Spring através do Java (via anotações). Depois de iniciar o desenvolvimento e experimentar as funcionalidades, repensamos a estratégia, uma vez que a versão naquele momento não atingia todas as metas que tínhamos definido.
Inicialmente também tínhamos planejado o suporte ao padrão Servlet 3.0, mas encontramos alguns problemas com as implementações existentes. Realizamos iterações com as equipes envolvidas para garantir que essas implementações funcionassem corretamente.
Mas a principal razão para o atraso foi termos intencionalmente aumentado o escopo, para incluir o suporte ao Java 7 na versão 3.1, ao invés da 3.2. Isso incluiu o suporte ao framework fork/join e a JDBC 4.1.
Decidimos suportar o Hibernate 4 bem cedo, antes mesmo do lançamento dessa versão final. Atualmente, o Spring 3.1, utiliza a versão release candidate 7 do Hibernate, sendo que o Spring 3.1.1 será atualizado para o Hibernate 4.0 final, quando esta versão for disponibilizada.
Vale a pena mencionar que não trabalhamos orientados a data, mas sim na entrega da melhor versão possível. Isto está relacionado a coesão e completude, garantindo que entregamos algo que realmente faz sentido aos usuários.
InfoQ: O fato de o Spring já suportar o JDK 7 indicaria que a adoção para o Java 7 tende a ser mais rápida do que foi com o Java 5 e 6?
Vemos um grande potencial nessa JDK. Tivemos contato com o Java 7 nas releases disponibilizadas pelo OpenJDK e pela IBM. Esperamos que a adoção ao JDK 7 por outras empresas aconteça de forma rápida e pretendemos de alguma forma estimular essa adoção. Implementar no Spring Framework o suporte a Java 7 é prova disso.
InfoQ: O Spring 3.1 tira proveito de outras características do Java 7, como try-with-resources ou alguma outra funcionalidade do Projeto Coin?
Mantemos isso em mente (da mesma forma que as novas funcionalidades do Java 8), mas não há muito dessas funcionalidades no Spring 3.1. A maioria dos recursos como multi-catch, try-with-resources, além dos strings em switch, são convenientes quando se está trabalhando diretamente na API. Dessa forma não têm impacto sobre a forma que a API é utilizada. Mas vale a pena ressaltar que o Spring 3.2 terá foco em JMS 2, e nesse caso faz sentido o uso try-with-resources.
InfoQ: Você mencionou o novo conceito do Spring 3.1 implementado para abstrair o ambiente de execução. Poderia nos dar exemplos aonde isso poderia ser utilizado?
O conceito de abstração de ambiente é dividido em duas subcategorias: a primeira é a ideia de abstrair no código as propriedades relacionadas ao ambiente; a segunda é a de relacionar beans com profiles.
No universo Java quando é necessário armazenar e recuperar propriedades ou informações pertinentes a uma determinada configuração, há várias opções: utilizar variáveis do ambiente operacional, propriedades da JVM, um Map, criar um objeto que encapsule essas propriedades ou mesmo um banco de dados para manter essas informações.
Mas, semanticamente, todas essas opções têm algo em comum: são basicamente configurações que mudam de ambiente para ambiente. A abstração de propriedades é um simples SPI [Service Provider Interface] que pode ser implementado em qualquer estrutura que armazene os dados baseando-se em pares chave/valor, com o propósito de manter as configurações das aplicações. Essas configurações são mantidas pelo Spring de forma hierárquica e conforme o estilo da aplicação. Por exemplo, o StandardEnvironment do Spring foi projetado para aplicações standalone, que rodam fora do contexto de containers, portanto representa informações de variáveis de ambiente e/ou propriedades da JVM.
Para aplicações web, o StandardWebEnvironment do Spring controla informações como parâmetros de Servlets (init-params), parâmetros de contexto (context-params) e propriedades JNDI, tudo na mesma estrutura. Esse conceito de ambientes está fortemente integrado ao container ou ao ambiente de execução do aplicativo, a ideia é prover uma camada consistente que abstrai do usuário a forma que são acessadas essas informações. O desenvolvedor pode dizer, "Spring, retorne o valor de tal propriedade", sem que a aplicação se preocupe em implementar código para verificar o ambiente.
A opção de vincular beans a um Profile, traz a capacidade de vincular um bean a um determinado ambiente de implantação (desenvolvimento, produção, ambiente de nuvem). Pode-se por exemplo, no ambiente de desenvolvimento, utilizar um banco de dados embutido, e em produção substituir esse componente por um datasource JNDI tradicional.
Os usuários do Spring Framework vêm solicitando mudanças há bastante tempo, para resolver problemas com as configurações dos diversos ambientes em que um aplicativo opera. Estamos ansiosos para ver os novos recursos sendo utilizados.
InfoQ: A outra grande mudança dessa versão é o Spring Cache. Qual é o posicionamento do Spring Cache em relação ao Spring Data?
A abstração da camada de cache implementada no Spring 3.1 é um SPI consistente, formado pelas interfaces Cache e CacheManager. Essas interfaces devem ser implementadas pelo provedor de cache subjacente. Os desenvolvedores podem configurar essas funcionalidades via programação através das anotações: @Cacheable, @CachePut e @CacheEvict.
O Spring Data é um projeto "guarda-chuva", formado por uma coleção de outros projetos que fornece acesso a diferentes tipos de datastore, utilizando mecanismos do próprio Spring. Graças à integração que já foi implementada, é possível utilizar algum desses datastores como provedores de cache no Spring Cache, como o GemFire e o Redis. Independente de qual é o provedor, o desenvolvedor precisa conhecer apenas as anotações do Spring Cache.
InfoQ: Qual é a sobreposição do Spring Cache em relação ao JCache (JSR 107)?
Eu diria que são projetos complementares. Por se tratar de uma especificação, certamente teremos uma camada que unifica o JCache com o nosso SPI, permitindo por exemplo que uma interface JCacheCacheManager seja utilizada como CacheManager. Da mesma forma que foi implementada a integração com o Spring Data, faz todo o sentido permitir que o SPI utilize uma solução JCache, aumentando as alternativas para o backend do Spring Cache.
Falando sobre o modelo de programação, existe uma sobreposição entre as anotações. Em alguns casos algumas anotações têm o mesmo nome; em outros o mesmo valor semântico. Algo parecido aconteceu no lançamento do Spring 2.5, com as anotações @Autowired e @Inject, padronizadas mais tarde no Java EE.
InfoQ: Você está seguindo a JSR 347 [Data Grids]? Vê algum impacto no Spring Cache?
A JSR do JCache ainda não está completa, e dado que a JSR 317 baseia-se nela, é um pouco cedo para especular sobre o futuro. Do ponto de vista do Spring, a especificação não tem muito a ver com o que estamos fazendo. Nós basicamente criamos um modelo consistente de programação e um SPI simples integrado a um repositório. Esse repositório, da perspectiva do JCache, é só um datastore.
InfoQ: Você falou algumas coisas sobre o Spring 3.2 tais como JMS 2.0 e JCache. O que mais poderia dizer sobre o planejamento da nova versão?
Em relação a especificações, estamos examinando o JPA 2.1 e o Bean Validation 1.1. Também temos interesse em aproximar o Spring do JSF 2.2. Além disso, temos algumas áreas de pesquisa que demandam um investimento maior de trabalho; é o caso por exemplo da programação concorrente. Fornecemos suporte básico para o framework join/fork no Spring 3.1; mas quais seriam as mudanças no modelo de desenvolvimento utilizando esse framework? Essa é uma resposta que ainda não temos, não só o time do Spring mas toda a comunidade. Uma das nossas metas é explorar mais esse modelo de programação para obter respostas como essa.
Desenvolvedores Java atualmente podem tirar proveito das vantagens da programação assíncrona a API Servlet 3.0. Nesse ponto temos outras perguntas sem resposta, como: Qual a importância do padrão Servlet 3.0 em relação aos frameworks web? E qual o seu impacto para os desenvolvedores?
Também queremos manter a atenção em mudanças que afetam o desenvolvimento de uma aplicação para cloud. No momento, vemos fornecedores de PaaS (Platform as a Service) fazendo a coisa certa, ao adaptar a infraestrutura de nuvem ao modelo de componentes Java EE. Mas aqui cabe outra pergunta: Seria essa a melhor maneira de implementação, considerando as características de um ambiente de nuvem?
Chris Beams também falou sobre repensar o modelo de relatórios de erros do Spring, tornando o rastreamento de erros mais sucinto, nos moldes do javac, além de trocar o serviço de proxy doCGLIB por uma alternativa mais moderna, com ganhos em usabilidade. O Spring Framework, segundo ele, irá ainda mover o sistema de controle de versões de Subversion para Git/Github e o sistema de builds de Ant/Ivy para Gradle, assim que começar o desenvolvimento da versão 3.2.
O Spring 3.2 seguirá um plano agressivo. Inicialmente a meta para o lançamento é entre outubro e dezembro de 2012.