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.

73 Comentários

  1. camilo lopes 08/10/2012 at 23:15 #

    Breno,

    Acho que você está usando o composite de forma errada, eu estou em um novo projeto e adotamos JSF 2.0. Temos muitos composites, pois o sistema é grande e há páginas em comum, mas em areas diferentes, dai criamos composite genericos onde o faceban que for usar vai ditando as regras, há composite que até os styles são personalizados pela página que vai usar. E aqui não quebra nada, o segredo é saber usar bem os panelgrids, eles resolvem muito problema de layout.

    Sobre o post. Eu achei que foi válido, uma vez que o objetivo não é pra dizer se o JSF é uma boa/ruim solução. Mas, quem trabalha com versões pre-JSF 2.0, vai ver que o componente deu um salto e dos grandes, pois tem muita coisa que se tornou bem produtivo. E juntando com primefaces, fica realmente show e normalmente atende a 80% dos requisitos do cliente.Reiventar a Roda que não, muito menos adotar tecnologias por ego. Para o cliente final, pouco importa se vc fez em JSF ou qualquer outra coisa, importante que a tela esteja do jeito X com a funcionalidade Y. Claro que vamos buscar sempre a melhor solução disponível levando vários pontos em conta, mas digo sempre que não encontraremos “a melhor” e sim aquela que é ideal para o projeto e cenário que temos.

  2. Gustavo Antunes de Bitencourt 11/10/2012 at 14:32 #

    Se me permitem, o mesmo questionamento que eu fiz em um tópico que eu fiz do GUJ, farei aqui…

    Resumidamente… Já que alguns fizeram pouco caso do JEE…

    Para um projeto com +ou- 80, o que vocês usariam? Quais tecnologias/frameworks ou sei lá o que?

    Onde esse será melhor que o JSF ATUAL no seu ponto de vista?

    Abraço á todos.

  3. Breno 14/10/2012 at 11:43 #

    camilo lopes,
    não entendi o que falou. Vou ser mais claro. O que faço no jsf 1.2 é criar componentes para por ex. campos de formulário, column e declaro pelas taglibs. No jsf 2.0, com composite component, estou com problema quando eu crio um composite component (id=”combo01″) que precisa renderizar outro composite component (id=”combo02″) dentro do mesmo formulário (ex. “form01”). No atributo do meu component reRender, preciso sempre colocar (“form01:combo02”) pois o composite component é sempre amarrado a um UINamingContainer. Até utilizando insertChildren e declarando as ações na própria página não funciona.

  4. Rafael Ponte 16/10/2012 at 17:07 #

    Oi Breno,

    No JSF2 existe uma variável implicita (EL) em escopo de componente na qual tem referência para a instância atual do componente. Como a instância é do tipo UIComponent você pode obter o ID (através do método getId()) do componente e ter acesso aos demais métodos getters. Seria algo mais ou menos assim:

    Será que dessa forma não daria certo o que você quer?

  5. Rafael Ponte 16/10/2012 at 17:09 #

    Acredito que o código não foi exibido no último comentário. Enfim, você pode obter o ID da instância atual do componente com essa EL #{component.id}.

  6. Breno 16/10/2012 at 21:43 #

    Rafael Ponte, obrigado por responder,
    eu uso uma “div” html mesmo com o id=#{component.clientId} e resolve quando um componente jsf normal (selectOneMenu puro) atualiza o valor do meu composite component (combo2), pois pertencem a mesma árvore do form.
    O problema é que o composite component é sempre amarrado a um UINamingContainer, o qual delega os id’s dos componentes de dentro do composite.
    Meu problema:
    Quero criar um composite component para uma combo, pois não quero amarrar label e styles para cada combo (selectOneMenu).
    Quando eu selecionar o estado(UF), quero utilizar o evento () para mostrar em outra combo as cidades, porém, dá erro pois ele tá na árvore do composite delegado pelo UINamingContainer com o id “:form01:combo1:comboreal” e não enxerga a outra combo (combo2) com o id “:form01:combo2:comboreal. Tendo eu que colocar no update a árvore completa, començando por ex. do “:form01:combo2” para funcionar.
    Umas gambiarra seria utilizar o #{component.parentId} concatenando com o id da combo 2 no composi componet. Porém se o evento for declarado na página, não no composite, volta a quebrar.
    Não sei se estou falando besteira, mas, será se existe uma forma de não amarrar o composite a um UINamingContainer?

  7. Leonardo Baiocchi 23/10/2012 at 18:02 #

    Excelente post Rafael! Aqui estou firme no JSF2..Um abraço!

  8. Abraão Isvi 20/11/2012 at 13:33 #

    Eu estava meio resistente a usar JSF2, mas resolvi apostar.

  9. jorge 05/12/2012 at 13:22 #

    Excelente post, mas depois de 8 anos com java para web, principalmente com frameworks orientado a componentes como JSF, inclusive tendo o desprazer de trabalhar com outras plataformas como .Net e Asp.Net Web forms (felizmente a M$ deu um grande apoio ao Asp.Net MVC), não vejo sentido, nem produtividade em usar essas coisas , pelo menos em no mínimo 60% dos projetos web do “mercado”.

    Hoje me sinto muito mais feliz graças ao Ruby, ROR, Sintara etc. Obviamente, acompanho de perto a “evolução” do Java(linguagem e plataforma) e a evolução do .Net(C# e Asp.Net MVC). Em resumo frameworks mvc baseados em componentes são “Uma cilada Bino!!”, os Front-End Developer piram quando veem JSF. Uma dica: Aprender melhor javascript(de verdade), html e css sai muito mais barato, o que agrada muito ao cliente, mas não necessário alguns devs.

  10. jhonathan 21/12/2012 at 08:26 #

    o JSF serve para desenvolver site ( dinâmico ) ou só sistema ?
    abraço

  11. Thiago.cmv 04/03/2013 at 14:05 #

    jhonathan – “o JSF serve para desenvolver site ( dinâmico ) ou só sistema ?” Serve para desenvolver qualquer site web. Claro que dependendo do seu contexto pode ser muito melhor utilizar outra tecnologia no lugar do java.

  12. Nesken 01/08/2013 at 15:36 #

    Qual versao do JSF voces estão usando com mais frequencia, 2.0 ou 2.1?

  13. Raphael Lacerda 01/08/2013 at 21:24 #

    2.1..

    saiu a 2.2 agora mas trocaram um esquema de inicialização do facelets.. nao consegui portar do 2.1 para o 2.2 nao

  14. Nesken 02/08/2013 at 00:41 #

    Rafael, mas pra começar um projeto novo, focando tambem html 5 bem melhor começar direto com o 2.2 né?

  15. Raphael Lacerda 02/08/2013 at 10:25 #

    Nesken, o Moreira experimentou o JSF 2.2 em sala e encontrou vários bugs.

    Eu ficaria ainda na versão 2.1.x

  16. Nesken 02/08/2013 at 16:05 #

    é o que estou usando tambem.. Valeu rapha, manda um abraço pro moreira…rsrsrs

  17. Stélio Moiane 09/12/2014 at 18:56 #

    Alguem com alguma evidência acerca do que se tem falado sobre o JSF?
    Uso a tecnologia ja a algum tem e nunca tive uma limitação que me colocasse a ponto de abandonar.
    Ficou bastante preocupado quando Organizações com nomes sonantes comentam em torno de uma tecnogia que uso com muita frequência.

    Alguma coisa? please peço a colaboração de todos.

Deixe uma resposta