Revisitando Internacionalização – Parte 2

Na primeira parte do artigo apresentamos uma estratégia para encapsular mensagens de internacionalização. Esta técnica consiste em associar um conjunto de Strings (já traduzidas para um determinado Locale) com métodos declarados em uma interface, utilizando a API do ASM para automatizar a geração da respectiva implementação. Esses objetos podem ser obtidos de forma programática ou referenciados de forma transparente em uma aplicação web gerenciada por um contêiner CDI.

Nesta parte do artigo veremos como a geração de código pode ser estendida de forma a contemplar algumas situações que são relevantes em ambientes de publicação de aplicações web ou corporativas e também para podermos trabalhar com métodos parametrizados utilizando tipos arbitrários (int, double, etc.), o que certamente melhora a compreensão do código acerca de quais valores devem ser utilizados para se formatar e exibir uma mensagem.

Por fim, veremos como podemos criar as classes de mensagens em tempo de compilação (ao invés de em tempo de execução), de modo que as mesmas possam ser referenciadas no classpath de uma aplicação, o que é mais apropriado em ambientes de produção.

Refinando a geração de código

Conforme vimos na edição anterior, nossa estratégia para a construção de mensagens de I18N é baseada em geração de código, o que nos poupa do trabalho mecânico de criar classes apenas para guardar valores fixos. Anteriormente apenas nos preocupamos em fazer a associação [Texto Traduzido]<=>[Método de Interface], que é suficiente para ser utilizado, por exemplo, em uma aplicação web gerenciada por CDI. Como o intuito é poder utilizar esta técnica em frameworks para aplicações Java EE, devemos nos preocupar tanto com características da especificação (ex.: criar referências serializáveis), como com aspectos não-funcionais, tais como não gerar overheads desnecessários pela introdução de um componente novo. Os próximos subtópicos discutem como essas peculiaridades também podem ser automatizadas no processo de construção das classes pela API do ASM.

Singletons: Minimizando o número de instâncias

Embora criar uma instância das classes geradas seja uma operação muito “barata”, pois as mesmas não possuem qualquer estado (todas as Strings são referenciadas diretamente nos métodos como se estivessem “hard-coded” e não são atribuídas a campos), podemos fazer uma pequena otimização de forma que apenas um único objeto seja instanciado para cada [Interface,Locale].

Para evitar que o método resolve() da classe I18NRepository (Listagem 8 da Parte 1) crie um novo objeto toda vez que for invocado, podemos tratar as classes construídas pelo gerador de código como Singletons, ou seja, precisamos que as mesmas contenham uma instância estática de seu próprio tipo, como demonstra a ...