Logo

Desde os tempos mais remotos, o JSP (Java Server Pages) sempre fez parte da especificação Java 2 Enterprise Edition (nossa conhecida J2EE 1.x). A idéia era simples: Servlets onde o foco for código Java, JSP onde o foco for HTML. A clássica divisão de responsabilidades entre designers e programadores.

Com a constante sugestão de alguns frameworks MVC populares em usar outros engenhos de templates em detrimento do padrão JSP, como Velocity ou FreeMarker, e ainda, desde o Java EE 5.0, com a inserção do JSF, que nunca se deu muito bem com JSP, a pergunta foi, será que o JSP ficou obsoleto? Agora no Java EE 6.0, o Facelets virou padrão e a própria documentação oficial que saiu agora em Junho quase esqueceu de falar de JSP. Seria JSP Já Se Phoi? (E se foi com pê-agá).

Clica aí no leia mais pra gente discutir esse assunto.

No princípio era o verbo, digo: o socket. Em nossas turmas de Java Developer, falamos sobre esse fundamento da programação distribuída. Como duas máquinas conseguem se comunicar em uma rede, preferencialmente via TCP/IP. Sempre acreditei que isso fosse interessante para quem ainda vai estudar Java para Web, porque podemos criar um exemplo construindo o browser e o servidor Web. Claro que o foco não é a reinvenção da roda, mas a discussão sobre a necessidade de um protocolo de comunicação que diga quem escreve e quem lê e qual o formato da escrita para que a comunicação se dê plenamente.

No Java Enterprise, existe a figura do servidor Web, como o nosso conhecido Apache Tomcat. A função dele é responder à onipresente outra figura que não necessariamente é escrita em Java, o browser, conhecendo plenamente o protocolo HTTP (obviamente que bem mais aprofundado do que no nosso curso Java Developer) e já entendendo que deve criar um objeto Java e chamar um método específico seu de acordo com a URL da requisição. Para os que já sabem disso, é aquela história do arquivo web.xml mapear um <url-pattern> para alguma <servlet> e a chamada ao método service() da servlet, que se for subclasse de HttpServlet, vai direcionar a requisição para um método como doGet(), doPost(), etc, de acordo com o método de requisição.

Para quem vem dessa linha, ou seja, quem aprendeu a programar em Java standalone, depois em rede, em rede com respostas concorrentes e finalmente caiu na Web, as Servlets são algo bem simples e interessante. No entanto, para quem aprendeu primeiro o HTML para criação de páginas estáticas, sabe como navegar na Internet e pretende tornar seu site mais dinâmico, ter que aprender Servlet pode não ser a coisa mais instigante da face da Terra.

O JSP entra justamente nessa lacuna. Fornecendo a capacidade de se escrever uma página HTML onde o programador (ou mesmo o designer) pode adicionar tags  <% e %> (e algumas variações que não vou entrar no mérito) e inserir assim conteúdo dinâmico à página. O problema é que mesmo quem nunca viu uma Servlet mais gorda na vida, vai acabar querendo escrever códigos de programação mais densos dentro dessas tags, conhecidas como scriptlets. O que vai acabar construindo um código que fora é HTML, dentro é Java. E esse Java acessa banco de dados, aplica regras de negócio, controla navegação, itera sobre resultados, enfim, faz tudo junto e misturado. Daí o termo código macarrônico.

Surgiram então soluções como JSP EL e JSTL que, juntas, dão mais cara de HTML e menos de Java aos códigos JSP e resolvendo detalhes como não precisar chamar get/sets dos objetos e misturar os escopos dos atributos setados na requisição, na sessão e na aplicação (engraçado, isso em PHP é visto como algo ruim, vai entender …).

O problema é que o JSP não se adequa muito bem ao mecanismo de alguns frameworks MVC e foi preterido pelos Struts I e II, por exemplo. Com JSF, a coisa foi ainda pior. O JSP não se encaixa no ciclo de vida de um componente JSF, o que torna as coisas mais lentas quando não dão erro. Um exemplo de erro é quando usamos a tag <c:forEach> do JSTL com tags JSF dentro. Se no interior dela inserirmos alguma tag com o atributo Id, a página não será renderizada quando houver mais de uma iteração da coleção varrida pelo <c:forEach>. No código abaixo:

<c:forEach items="#{meuBean.itens}" var="meuItem">
    <h:inputText id="elemento" value="#{meuItem.nome}"/>
</c:forEach>

Quando itens, uma coleção de qualquer coisa de meuBean tiver mais de um item adicionado, a página vai dar erro. Isso ocorre porque o JSP é processado antes. Quando chegar a fase JSF de renderização da página, o JSP terá sido executado e gerado duas linhas inputText com o mesmo id.

Já no código abaixo:

<h:dataTable value="#{meuBean.itens}" var="meuItem">
    <h:column>
        <h:inputText id="elemento" value="#{meuItem.nome}" />
    <h:column>
</h:dataTable>

Refizemos a mesma coisa usando apenas tags JSF. Aqui, tudo é executado no mesmo momento, chegando apenas um id elemento.

Na nova documentação oficial do Java EE 6.0, há uma passagem no mínimo curiosa:

“JSP is considered as a deprecated presentation technology for JavaServer Faces 2.0.”

Claro, não estou negando o fato de que nem sempre você vai precisar do JSF. Nesses momentos o JSP pode lhe atender. Enfim, o que acho estranho é o fato de depois de grandes investimentos sobre o JSP ele estar sendo resumido a pequenos códigos uma vez que se vende o JSF para aplicações corporativas. Fica a dúvida sobre o que fazer quando utilizarmos JSP em um projeto mais simples que depois se torne um grande sistema. Devemos trocar todo o legado por JSF+Facelets, manter o JSP mesmo que menos integrado com o background corporativo gerando um custo de manutenção mais elevado ou misturar os dois e investir em uma combinação considerada oficialmente obsoleta?

Posso mudar de opinião amanhã, mas pra mim JSP Já Se Phoi.