Java Framework Portal

PlayFramework Review

Posted on 14 March 2010

A pouco tempo fiquei conhecendo um novo framework para Java de alta produtividade, trata-se do PlayFramework http://www.playframework.org. A sua primeira versão estável foi disponibilizada em Fevereiro de 2008, e hoje se encontra na versão 1.0.1. Achei o framework interessante e resolvi escrever esse review.

Para testar o framework, fiz o tutorial do site que mostra como construir um blog. Foi bastante tranquilo, não deu erros inesperados e o tutorial estava bastante condizente com a construção da aplicação. Utilizei o eclipse para construir o projeto. O play vem com uma ferramenta que permite adaptar o projeto a várias IDEs de forma bem fácil.
A primeira coisa a se notar é que o play é um framework Java. Mas não é um framework JEE. Eu não vejo problema nisso a principio, mas ao invés de manter só o framework, o desenvolvedor do play, terá que manter também, uma arquitetura, um servidor, etc. Ainda não sei o que ele usa por baixo dos panos, mas seria bem viavel se utilizasse algo como um Tomcat turbinado.
Eu acho que o JEE hoje, com a utilização de frameworks não tem tanta importância na arquitetura da aplicação, a não ser para criar um request e response, e fazer a comunicação HTTP. No caso do JSF, por exemplo, request e response praticamente nem existem. O JEE, mesmo com as últimas versões, não oferece grande vantagem já que voce usará um framework por cima. Até mesmo o JSP está saindo de linha. E isso se deve ao fato de suas limitações. O pessoal acaba deixando de lado os recursos do JEE e criando o próprio engine.
Um outro aspecto, que faz grande parte das mágicas, que permitem ao play ser bastante produtivo é a utilização de um Java Agent. Esse java agent, apesar de eu não ter estudado a fundo, deve "tunar" as suas classes em tempo de execução. Fazendo os getters e setters que você não escreveu, implementando os métodos do Model e fazendo o Hot Deploy do seu projeto sem a necessidade de reiniciar o servidor. Um Class Loader especial provavelmente ajuda nesse processo também.
Hoje a maioria dos frameworks utilizam a manipulação de byte codes para facilitar o desenvolvimento. Essa manipulação permite que sejam feitas algumas coisas pelo usuário, que, na verdade, é a tarefa do framework. Antes da proliferação dessa técnica o que acontecia, é que o framework elevava a aplicação a um nível de abstração bem mais alto para poder trabalhar numa cama intermediária entre a JVM e a aplicação. Hoje os frameworks atuam entre o bytecode e a JVM, mantendo a camada de aplicação sobre o Java puro, ao invés de sobre uma camada do framework. Isso facilita bem o desenvolvimento e o aprendizado das ferramentas.
O esquema de redirecionamento também é bastante interessante. Quando você faz por exemplo:

GET     /posts/{id}                             Application.show 

O framework permite que acesse um post com a URL /posts/6, utilizando conceitos RestFull. Mas vai além disso, se você utilizar no seu código um redirecionamento como:

@{Application.show(post.id)} 

O framework irá ver que Application.show tem um route, e vai renderizar o link como /posts/${post.id}. Ou seja, faz a leitura ao contrário também. Isso eu achei bem legal.
A configuração do framework é através de arquivos de properties, que por sinal são bem completos. Esses arquivos são documentados e você quase não tem que escrever neles, já vem tudo pronto praticamente. Se quiser alguma configuração ou funcionalidade apenas descomente alguma linha do arquivo.
A linguagem utilizada nos templates tem bastante poder, e utiliza groovy para fazer o evaluation. Oferece uma sintaxe especial para diversos tipos de funcionalidade: # para chamar scripts ou tags, @ para links, etc. Isso torna a leitura do código fácil depois que voce acostuma com os símbolos. O sistema de includes das páginas também é legal, pois permite que sejam utilizados templates dentro de templates.
Os controllers são bastante simples de se escrever, sem segredo. E oferece um esquema de validação e mensagens, igualmente simples.
O framework tem uma característica de ser Stateless. Ou seja, você não deve guardar estado nos objetos. É uma arquitetura válida, não é necessário voce ter milhoes de objetos cada um num escopo diferente para ter uma aplicação robusta e bem implementada. Essa variedade de escopos usadas em alguns frameworks, acaba inclusive causando alguns problemas.
Uma outra feature que estudarei mais profundamente e me interessou, é que a sessão é gravada em cookies. Isso pode ser uma grande vantagem do framework. Já que não é utilizada memória do servidor, a aplicação pode escalar melhor.
A ferramenta parece ser bastante estável. Não apresentou erros durante o desenvolvimento. O tutorial é bem explicado, e tem boa documentação.
Vamos dizer assim que é um framework bem redondo.

Algumas críticas:
Natureza static: Apesar de concordar com a natureza stateless, não concordo muito com a natureza static. Nos controllers os métodos são todos static e parece que a ideia é trabalhar assim no framework, acho que é uma desvantagem bem grande, e deve ser revisto.
View: A linguagem utilizada em templates é bastante poderosa, mas as views são escritas praticamente com HTML. E as tags também são assim. É como se voce tivesse tag files do JSP, mas não tenha tags mesmo, escritas em Java.
Sobrescreve o JEE: O play é tudo: framework, servidor, ferramenta. Isso vai tornar mais complicada a adoção e também a evolução do mesmo, já que tem muito código a ser visto. O pacote do play tem 45 Mb. É muita coisa, é claro que por baixo dos panos foram utilizadas outras ferramentas. Mas como a integração é feita pelo play, esse código tem que ser mantido por ele.

Considerações finais:
O Play parece funcionar realmente, foi bastante estável nos testes feitos. O sistema de deploy é excelente. É produtivo e fácil. Apesar de ter todas essas vantagens, e que ele está seguindo a tendência, praticamente todo o framework pode ser substituído por ferramentas que existem no mercado. A grande vantagem do play é que já vem tudo pronto e configurado.
Para ter um framework igual ao play, você pode utilizar por exemplo o Spring. No controller utiliza algo como VRaptor ou Next, que são baseados no Spring MVC. Orientação a aspectos, para fazer os métodos que não são implementados por você como os getters, setters e métodos do Model. E utilizar um template mais poderoso do que o JSP. As queries já são contruidas com JPA mesmo. Aí você já tem um play. Com alguma configuração de class loader e java agent, você consegue o mesmo deploy. A diferença é que nesse caso você estará no Standard, ou seja, usando tomcat, eclipse, plugins, tudo que todo mundo já utiliza. Ao invés de jogar tudo fora e começar do zero.
Não estou criticando o framework e falando que ele é ruim por causa disso. Pelo contrário, acho que ele fez tudo certo, utilizando tendencias de mercado e tudo mais. Só que você começa de uma plataforma nova e isso dificulta bastante a adoção.
Apesar tudo que tem no play, existir no mercado, existe uma grande vantagem do play. Ele já está todo configurado e funcionando, as interfaces já foram testadas e estão estáveis. E não é fácil montar uma arquitetura dessa, gasta muito tempo, testes e código. E não é qualquer programador que consiga fazer isso.
A minha crítica em relação ao play é que ele poderia utilizar algumas ferramentas que já existem, mesmo que existam limitações, com um pouco de raciocinio, poderia ser feito algo muito semelhante senão igual ao que o play é hoje. E esse é o grande desafio de se desenvolver frameworks, partindo do que já existe, como podemos melhorar? Fazer tudo de novo, é claro que teremos algo melhor. Fazer melhor com a base instalada que é o difícil. Então vejo o play mais como uma proposta de como fazer, do que realmente adotá-lo em larga escala.
Utilizaria o play em algum projeto? Sim.
Mudaria alguma coisa nele? Sim, faria uma camada facilitadora do que já existe, e já configurada, ao invés de criar tudo do zero. Assim a adoção poderia sem bem maior.
No mais, gostei da ferramenta, e vou estudar alguns aspectos mais profundamente. Achei bastante válida a iniciativa.