10 razões para migrar sua aplicação para JSF 2

Você optou por um framework component based, escolheu trabalhar com JSF e ainda não sabe se deve encarar riscos e custos de migrar para a (não tão) nova versão da especificação? Vale a pena?

JSF 2 surgiu em 10 de dezembro de 2009 fazendo parte do JavaEE 6. Trouxe uma série de mudanças que todos já até cansaram de ouvir falar: simplificação através de anotações, suporte a GET, Ajax Nativo, ViewScope, Facelets como renderizador padrão, dentre muitas outras. Após quase 3 anos da liberação da API, vale a pena mudar agora?

Eu e Rafael Ponte, um ativo participante da comunidade e conhecedor de JSF, enumeramos 10 razões que podem ajudar a sua decisão. Elas também valem se você estiver pensando em adotar um framework component based para um novo projeto.

1. Desempenho

JSF sempre foi considerado um framework com problemas graves de desempenho desde suas primeiras versões (RI 1.0/1.1). No entanto, após o lançamento do JSF1.2 muitos dos problemas de performance foram resolvidos graças ao talentoso time de desenvolvedores da Mojarra (RI). Mas ainda assim, devido a limitações de design na especificação do JSF1.2, o time de desenvolvedores sempre teve dificuldades para escrever código performático. Somente com a especificação do JSF2 é que tornou-se possível escrever código desde o ínicio com performance em mente.

A extensibilidade e as novas features (como Partial State Saving, Tree Visiting e Project Stage) do JSF2 tem permitido melhorias significantes de desempenho a cada release. Melhorias como o menor consumo de memória (até 4x menos) e cpu, menor latência, melhor gerenciamento do estado de cada componente, otimização no algoritmo de busca de componentes e de serialização da árvore de componentes, cache de EL expressions e outros.Indo mais além, é possível que o JSF2.2 (ou um futuro release) adote uma configuração que vá em direção contrária à natureza Stateful do framework, o Stateless Mode. Com este modo stateless não haverá a necessidade de criar a árvore de componentes a cada request (teremos um cache de cada view), o que diminuirá o uso de memoria e cpu e trará um ganho de até 30x no número de requisições por segundo em uma página complexa.

1. Melhorias na Especificação

São muitos os pontos de melhoria, mas gostaremos de ressaltar alguns, principalmente no que concerne à evolução/futuro da plataforma. Ficamos muito tempo parados no JSF1.2 e não vimos progresso na especificação. Contudo, parece que o jogo mudou. Alguns itens que ficaram em aberto no JSF2.0, como a falta de integração do @ViewScope com a combinação JSF + CDI, já estão previstos para serem resolvidos no JSF2.2, assim como melhorias no suporte ao HTML5, AJAX e navegação com o Faces Flow e outros itens resolvidos já no JSF2.1.

1. Mais componentes!

O número de componentes tem crescido a cada dia devido a facilidade de se implementar componentes no JSF2. Os principais conjuntos de componentes (Primefaces, Richfaces, Trinidad e Icefaces) já possuem um excelente suporte a nova especificação e cada um deles possui diferentes sabores de componentes ricos para praticamente todos os tipos de aplicação. Devido a features como Ajax Nativo e Resource Loading estes mesmos conjuntos de componentes tornaram-se compatíveis, o que tem possibilitado integrá-los sem muitas dificuldades em um mesmo projeto - o que era quase impossível com JSF1.2.

Outro ponto interessante é que com o sucesso do JSF2 as empresas mantenedoras tem diminuído o suporte e a implementação de novos componentes JSF1.2, e, provavelmente, em médio prazo será ainda mais raro obter correções e melhorias para esses componentes de forma gratuita.

1. Adoção do Primefaces 2.x e 3.x

No tópico anterior ressaltamos sobre a variedade de componentes, nesse ousamos afirmar que o Primefaces (2.x/3.x) está tão interessante que seu uso por si só já é um motivo para migrar. Eles sairam na frente do RichFaces como implementação de componentes compatível com JSF 2. Só esse aspecto já seria o suficiente para ter uma adoção maior. Entretanto, o principal motivo foi a qualidade dos componentes. Comparando as demos de ambos constate-se que o primeiro possui uma variedade muito maior de elementos, além de suporte com componentes mobile. Ainda mais, ele usa o ThemeRoller, facilitando a customização de acordo com sua necessidade.

Outro ponto que podemos citar é a evolução. Enquanto o Primefaces já está na 3.X (segunda geração compatível com JSF 2), o RichFaces ainda está na 4.X (primeira geração compatível com a tecnologia). Você pode conferir diversas comparações que o pessoal no mercado fez, inclusive destacando alguns pontos de desempenho, para ajudar em suas conclusões.

1. Maturidade

A adoção do JavaEE 6 pode ser considerada um sucesso, fato esse pois discussões antigas sobre JavaEE vs Spring voltaram, e antigamente a especificação perdia fácil (quem não se lembra daquela MundoJ - EJB X Spring). Atualmente o Java EE tem uma boa relação com outros frameworks, como o Spring.

1. Adoção do CDI

CDI é a especificação para Injeção de Dependência (JSR-299). Surgiu também com o JavaEE 6 e foi prontamente adotada pela comunidade, inclusive integrando com linguagens como Ruby (projeto TorqueBox). Já teve inclusive alguns estudos para identificar o desempenho de aplicações que usam a API e concluem como a implementação de referência Weld evoluiu e ainda tem a evoluir. Com a especificação conseguimos algumas manipulações bem avançadas como, por exemplo, injeção de dependência para objetos genéricos.

1. Envolvimento da comunidade

Há muito movimento ao redor do JSF2 e do CDI. Recentemente foi lançada pelo Bauke Scholtz (talvez o developer mais proeminente na plataforma) o OmniFaces, que é uma biblioteca utilitária para consertar vários problemas que ainda não foram melhorados na especificação. Temos também outros projetos mainstream como o Seam3, CDISource e Apache CODI. Há um claro sombreamento de funcionalidades entre os projetos, porém a cooperação dos times está tão grande que todos resolveram juntar forças em um só projeto, o DeltaSpike. O projeto agora é o foco da comunidade, e para comprovar isso, Pete Muir recentemente enviou um email na lista do seam-dev explicando que o projeto está a pleno vapor.

1. Suporte ao HTML5

Há muitas funcionalidades interessantes na especificação e ver o JSF tentar se alinhar mostra cada vez mais a preocupação da tecnologia em melhorar a User Experience.

1. Fim do suporte à versão antiga

Aqui entra uma questão mais enterprise. Algumas empresas contratam Oracle, JBoss, IBM, justamente pelo suporte que elas oferecem aos seus produtos. Portanto, é importante identificar a data de expiração desses serviços. Uma outra preocupação é com relação a variedade de implementações para a especificação JavaEE. Alguns vendors demoraram a soltar os seus releases compatíveis, mas temos até alguns menos conhecidos que estão certificados, como Apache Geronimo e Caucho Resign. Há também melhorias consideráveis de desempenho no JBoss 7 e GlassFish 3.1.

1. Custos

É um tópico complicado e possui uma série de variáveis envolvidas mudando para cada empresa. Entretanto, podemos citar alguns pontos relevantes a serem considerados, como se a sua empresa usa JSF 1.2 puro ou acoplado a algum outro framework como o Seam 2.x. Com a primeira opção, a migração é fácil, e a quantidade e qualidade das novas funcionalidades que entraram na especificação compensará todo este trabalho. Em relação a segunda opção, está saindo do forno o Seam 2.3 que possui suporte ao JavaEE6. Entretanto, não sabemos ainda como será essa nova atualização.

Uma opção disponível é a combinação Seam3+JSF2+CDI, e as novas funcionalidades dessa união foram livremente inspiradas no que o Seam 2.x já provia.

Precisamos ainda considerar um outro ponto relevante: o sistema possui testes automatizados? Unidade, Integração e principalmente Sistema? Caso negativo, seus custos podem ser bem mais altos do que você espera, pois descobrirá incompatibilidades e pequenos problemas de maneira inesperada.

Abordamos aqui muitas das vantagens que você obterá ao encarar essa migração. Dê os primeiros passos com JSF2 e sinta já a diferença. Muitos desses tópicos e outros são discutidos no nosso curso de JSF. Uma outra forma de começar é através do livro de JSF e JPA da Casa do Código.