10 razões para migrar sua aplicação para JSF 2
Postado em 19. set, 2012 por Raphael Lacerda em Java
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.
Raphael Lacerda
Mais sobre o autor
65 Respostas para “10 razões para migrar sua aplicação para JSF 2”
Trackbacks/Pingbacks
-
-
setembro 19, 2012
[...] foi publicado no blog da Caelum um post sobre as 10 razões para migrar sua aplicação para JSF2, e eu tive o prazer e a honra de colaborar com o post a convite de um grande amigo, o Raphael [...]
-
-
outubro 17, 2012
[...] http://blog.caelum.com.br/10-razoes-para-migrar-sua-aplicacao-para-jsf-2/ [...]
-
-
novembro 27, 2012
[...] Clique aqui e veja 10 razões que o pessoal do Blog da Caleum descreveu para ajudar na sua decisão. [...]
-
-
dezembro 26, 2012
[...] 10 razões para migrar sua aplicação para JSF 2Por Raphael Lacerda, em 19/09 [...]
-
-
maio 4, 2013
[...] utilizar esse escopo, existe projetos para atender essa não integração entre o JSF2 e CDI (li no blog da caelum que na versão 2.2 já existirá uma solução nativa pra isso). Googlando encontrei o MyFaces [...]


ASSINE NOSSO RSS
Gustavo Antunes de Bitencourt
11. out, 2012
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.
Breno
14. out, 2012
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.
Rafael Ponte
16. out, 2012
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
UIComponentvocê pode obter o ID (através do métodogetId()) 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?
Rafael Ponte
16. out, 2012
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}.Breno
16. out, 2012
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?
Leonardo Baiocchi
23. out, 2012
Excelente post Rafael! Aqui estou firme no JSF2..Um abraço!
Abraão Isvi
20. nov, 2012
Eu estava meio resistente a usar JSF2, mas resolvi apostar.
jorge
05. dez, 2012
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.
jhonathan
21. dez, 2012
o JSF serve para desenvolver site ( dinâmico ) ou só sistema ?
abraço
Thiago.cmv
04. mar, 2013
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.