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