Hey Hey Hey Hey Hey Hey Hey Hey Hey Hey! Do you wanna drink some alcohol?

Agora em novo endereço: www.objectzilla.com.br. Atualize-se, este conteúdo será logo removido. Mas não se assuste, como esse texto tem alguma coisa de interessante, eu farei uma versão atualizada lá. E só removerei este texto depois de passar o link aqui.

Muita gente do Java tira suas dúvidas e responde as dúvidas dos outros no Orkut GUJ, tem gente “estrela” lá, e tem até moderadores que ficam moderando o que possa parecer imoderável. Mas o que muita gente desconfia mas que não ousa falar é que todo mantenedor de fórum A-DO-RA quando ocorre uma discussão inflamada, pois todo o trabalho que eles tiveram para manter o fórum foi recompensado pela briga alheia. Mas é claro, precisa ter uma boa pauta pra começar uma discussão. Não foi o que aconteceu com o The Server Side, onde eles tiveram a idéia mais boboca do mundo: qual é o melhor? Struts ou JSF?

Tinha tudo pra ser mais uma lenga-lenga sem fim até que Bruno Borges apareceu e colocou um post em inglês que se resume a dois tópicos:

1. Craig McClanahan era o homem errado na especificação do JSF, pois trouxe a “tríplice aliança” (configuração em xml, código em Java e expression language) do Struts para o Faces.

2. Especificações perdem velocidade em relação a frameworks fora dos padrões.

Vou inverter e comentar o segundo tópico primeiro. A “velocidade” que o Bruno falou não deve ser considerada uma qualidade mais importante do que todas as demais. Para exemplificar, vamos fazer a seguinte analogia: imagine que um graçom esteja encarregado de servir copos grandes de chope para os clientes de um bar. Nesse copo, estão marcas com as seguintes indicações: 300 ml, 600 ml, 900 ml e 1200 ml, e o cliente pode pedir na medida em que desejar. Então, o que o garçom deveria fazer?

a) encher o copo na marca de 1200 ml e só colocar menos se o cliente explicitamente pedir, ou;

b) encher o copo na marca de 300 ml e só colocar mais se o cliente explicitamente pedir?

Se ele for honesto, ele deve seguir a orientação b; porque existem dois extremos de consumidores, aqueles que bebem pouco e aqueles que são beberrões, e esta opção é o que melhor satisfaz a ambos pois os que bebem pouco não serão obrigados a pagar por aquilo que não querem beber, e os beberrões não vão se importar em ter que dizer que quer bastante.

Agora imagine Java: existem dois extremos de ambientes de software, os conservadores, que precisam criar aplicações que rodem nas organizações por anos sem que haja necessidades de reengenharia, e os “early adopters”, que criam aplicações inovadoras e cujo tempo de vida estará limitado à próxima inovação. Agora eu pergunto: que tipo de servidor de aplicações seria mais adequado para ambos?

a) Um servidor com as últimas novidades em frameworks, ou;

b) Um servidor com apenas as soluções já conhecidas?

Novamente, se quem fez o servidor for honesto, ele escolhe a opção b, pois quem é conservador não é obrigado a instalar junto aquilo que ele achar muito novo (e por conseguinte, muito arriscado), e quem é “early adopter” não iria se importar em colocar módulos extras que estão mais na ponta.
Eu não acho errado a Sun esperar um ano ou dois para colocar idéias desenvolvidas pela comunidade no Java EE, esse é um período onde aqueles frameworks passarão por um “choque de realidade” e terão seus pontos fortes e fracos destrinchados. Assim, os caras de especificação podem decidir entre rejeitar uma idéia que não se mostrou promissora, ou adaptar idéias legais tentando minimizar os pontos fracos dos frameworks não-padrões (e por isso, eu prefiro que a especificação faça uma nova especificação do que simplesmente incorporar os frameworks de sucesso).

Bom, quanto ao seu primeiro tópico, isso é assunto para o meu próximo post.

P.S.: O título é uma homenagem à musica Alcohol do grupo Cansei de Ser Sexy (CSS).