Especificação.. Para o bem ou para o mal

rogelgarcia:

Já ví várias pessoas defendendo tecnologias como JSF com o seguinte argumento:

“É especificação!” ou então “É padrão!”

Perguntem pro pessoal da Oracle (finada Sun) se eles estão muito preocupados com o JCP, na hora de definir o Java 7.

Embora seja interesse comercial da Oracle(Sun) em definir o que faz parte ou não, acho que a especificação serve pra dar um “norte” a toda comunidade, e a outros frameworks, que surgem, principalmente pra suprir a falta ou falha de algo na especificação, como é o caso do JSF.

Ao quesito “minha escolha” isso é muito relativo, uma vez que hoje, um programador java faz mais integrações de frameworks do que escrever código propriamente dito(eu acho ótimo pois me sobra mais tempo). Mas o ponto é que, a gente sempre escolhe o que gosta ou tem mais afinidade. Gosto do primefaces, e com jboss seam e hibernate, faço aplicaçõea a jato. Gosto mais ainda de groovy e grails, mas meu chefe me colocou num projeto com gwt (num gosto) mas se isso paga minhas contas, que mal tem ?

Importante é se o resultado final atende a proposta do projeto.

TEORICAMENTE, a especificação é boa porque foi analisada, revisada e aprovada pela comunidade (JCP).

O problema é que algumas especificações parecem ser feitas não com o objetivo de serem produtivas por si só, mas para depois os vendors que escreveram a especificação poderem vender suas ferramentas baseadas na especificação…

Acho que o JSF é um caso assim, muitas vezes venderam JSF como um concorrente do ASP.NET, que é baseado em componentes e tem uma IDE por trás com um belo editor WYSIWYG. Lembro que quando comecei a estudar JSF tinha uma pela propaganda do Sun Studio e outra do JDeveloper, falando que JSF dava a possibilidade de se construir editores WYSIWYG e mostrando os editores com todos os seus wizards e seus drag & drops.

Sem falar no EJB pré EJB 3, com seus diversos XML, Homes, interfaces locais, remotas, stubs, etc. Era inviável usar EJB sem uma ferramenta que gerasse toda esses códigos repetitivos.

Há quem diga que essa tendencia de complicar demais a especificação para depois poder vender uma ferramenta pra aumentar a produtividade é algo proposital… Ou que essas especificações são demasiadamente complexas por que quem as escreve não desenvolve software “comercial” no seu dia-a-dia e acabam não tendo foco em coisas que realmente ajudam os desenvolvedores.

Odeio JPA ! :x

Amo hibernate 8)

lelodois:

Odeio JPA ! :x

Amo hibernate 8)

Why?

O Rubem conseguiu sintetizar todo o meu pensamento

Inclusive no caso do JSF… já mudou o foco umas 3 vezes…

Primeiro era pra poder com componentes gerar qualquer tipo de output… lembro que existia uma promessa de se trocar o renderer… e com a mesma árvore poder renderizar HTML ou GUI
Depois o lance das IDEs que o colega falou
Depois eles viram que não dava certo e ignoraram as idéias iniciais…

No entanto… a complexidade que já era alta no inicio… continuou crescendo…

Sobre os EJBs… nem se fala… e mesmo os EJB 3… que o pessoal tem muuuito orgulho de ter criado… o mérito foi do pessoal do Spring… pois vendo o Spring funcionando é que tiveram a ideia de fazer o EJB3 daquela forma…

Sobre o JPA também considero que existam vários problemas… o primeiro: Se definiu uma especificacao… baseando-se numa implementação (hibernate)… O resultado é que a especificacao é a implementacao… ou seja… O program to interfaces not implementations se perdeu nesse meio…
A ideia de se trocar a implementacao do JPA numa aplicacao… é praticamente nula… (rarissimo isso acontecer)
Se vc precisar trocar de Hibernate para EclipseLink por exemplo… vai ser porque precisa de funcionalidades especificas … ou seja… JPA vai ter que ser derrubado aí…
Enfim… no JPA tentaram trocar seis por meia duzia… pq depois de tanto tempo… ainda não houve vantagem REAL em se utilizar JPA…
A grande vantagem que eu vejo… que nao se traduziu em vantagem real pois o JPA sempre está um passo atrás … é abrir oportunidade para outras solucoes diferentes de hibernate… sem ter que aprendermos novas APIs…
É muita especificacao, código, ferramenta, coisa pra aprender, para pouca melhoria do desenvolvimento (pelo contrario… o desenvolvimento tá cada vez pior)

Um outro ponto que gostaria de adicionar… é que nessas votações de especificacao… tem mais política do que técnica… cada um tentando puxar a sardinha para o seu lado… ao invés de votarem em coisas que realmente tragam benefícios…