O que seria melhor para o JEE 6?

Olá

Há 2 grandes vertentes para as aplicações corporativas:

1- Não oficial mas muito usada: Hibernate + Spring + Spring-WS + Spring-OSGI + demais coisas com plugins para o Spring + uma tonelada de XML

2- Oficial: Seqüência de JEEs da Sun que é uma evolução lenta que começou com um lixo como o JEE 1.2, passou para a porcaria do JEE 1.3 evoluiu para marromeno JEE 1.4 até o atual JEE 1.5 que tem algumas coisas boas porque foi a primeira que percebeu que tinha coisa melhor lá fora.

[]s
Luca

This message was edited 1 time. Last update was at 18/09/2007 16:49:33

o hibernate de certa forma é o grande responsavel pela jpa, não?

hehee.... se eu fosse seguir as duas grandes vertentes que vc citou eu votaria na vertente numero 1 que parece mais amigavel.

Acredito que se o hibernate e Spring forem incluidos na especificação J2ee, outras alternativas irão surgir paralelamente a esta especificação e isso pode virar uma bola d neve.......

Talves seja bacana continuar sendo uma alternativa a especificação!

Debugger Membro desde: 15/12/2006 10:58:30 Mensagens: 58 Offline

Cara o hibernate é o grande responsavel pela JPA, então praticamente ja esta dentro. Agora o Spring não é nem de longe o framework mais utilizado, quanto mais cogitar incluir o mesmo no JEE 6.

JavaGuru Membro desde: 25/09/2006 23:10:20 Mensagens: 222 Offline

O JEE 1.5 não tem alguns recursos de IoC? Isso me faz lembrar um pouco do Spring...
Quanto ao JPA, como os outros disseram, é praticamente o hibernate.

Até

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

O Hibernate tá dentro do Java através da JPA. Agora quanto ao Spring, eu quero que fique fora e nunca entre no Java EE. Até porque hoje, o melhor container de injeção de dependência é o Guice.

E outra coisa. Que mania esse pessoal tem de achar que Struts devia ser oficial, ou que Spring devia ser oficial, ou que o framework X devia ser oficial. Meu, isso não muda nada. O mais importante que um framework deve conseguir é sua padronização de fato, não sua padronização oficial.

Olá

O Hibernate tá dentro do Java através da JPA

Na minha opinião, o JPA não passa de uma versão super light do Hibernate. O Hibernate em sí é muito mais maduro e completo, por exemplo, só agora que estão "pensando" em criar criteria pra JPA, que é algo que já deveria ter saido de fábrica. Delete-Orphan também. Tomara que a tendência seja do JPA ter ferramentas de apoio como tem o Hibernate (vide Hibernate tools, validator, search e shards)

Spring não tem nem o que conversar. As facilidades que ele disponibiliza pro desenvolvedor são enormes, desde IoC até web flow, passando por AOP, ORM e afins. Como faz falta um container de IoC descente pro JSF por exemplo, a única forma de incrementar aquilo é juntando com contexto do Spring.

Pra mim a melhor tendência é a não oficial. Quanto mais a Sun implementar esses tipos de frameworks e suas extensões, melhor ele ficará, porque quando se quer tentar inovar algo que já existe (e torná-lo padrão, tal como fizeram com o JPA) vai ser mais ou menos como voltar no tempo: terá que haver todo um tempo para o framework ficar maduro novamente, mais um tempo pra corrigir problemas, outro tempo pra criar plugins e ferramentas que auxiliam o desenvolvimento do mesmo e assim por diante.

4) Desistir do mesmo "Novo Java EE! Agora com mais Sbrubles!!" e simplificar a casa

Olá

Pena que algumas respostas demonstraram pouco conhecimento de Hibernate, JPA e Spring. Isto deve influenciar o resultado final. Só vou dizer que o JPA não faz tudo que o Hibernate faz e que o Spring não é só IoC. E ninguém falou das facilidades do Spring-WS sobre o JEE cru ou do Spring-OSGI comparado com o que a Sun vem preparando.

Para por mais lenha na fogueira, vou incluir alguns links:

JSR 313: JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification

http://www.infoq.com/news/2007/07/jee6

http://www.infoq.com/news/2007/04/jee6-wishlist

http://www.guj.com.br/posts/list/0/56298.java

http://www.infoq.com/news/2007/07/kingwishlist2

TSS-Rod Johnson: "Java EE 6 Gets it Right"

Sbrubles

[]s
Luca

This message was edited 4 times. Last update was at 18/09/2007 21:28:19

Acho que a especificação nunca vai ser tão ousada quanto as iniciativas da comunidade e essa vai acabar sendo influenciada, por tais.

Fazendo uma alusão ao meio da moda, acho que esses estão para a especificação assim como os desfiles e seus conceito, onde a maior parte das roupas não vão para as ruas, ou concept cars, que balisam o traço.

As companhias têm outra velocidade de adoção e em muitas delas a versão predominante é ainda java 1.4.

O Mule por exemplo, projeto de ESB é escrito sob java 1.4 e se vc fizer em 1.3 eles até preferem ( como commiter).

Algumas coisas acabam entrando na especificação, como IoC paulatinamente, substituindo factories, service locators e afins ... Ainda não é tão poderoso quanto o mecanismo do Spring, mas começa a mudar as coisas.

Uma consideração importante é que existem outros projetos que cobrem as mesmas tratativas, como o projeto do Google Guice, PicoContainer para IoC e na camada de persistência há outros projetos como o próprio TopLink da Oracle - isso para citar alguns.

Fica difícil eleger um produto para entrar na especificação, oq dá para fazer é tornar as melhores idéias parte da mesma. A própria JPA está evoluindo e na versão 2 entrá a Criteria, que ficou de fora e foi bastante criticada pela comunidade.

Acho bacana poder escolher o provider, utilizar a implementação OpenJPA sem ter de refatorar o código

Pra falar de Spring-WS, existe uma proposta nova JSR - http://www.jcp.org/en/jsr/detail?id=311 , provando que o pessoal agora está mais atento e indo na direção certa.

Só uma coisinha , concordo que o RoR fez o mundo parar pra pensar em desenvolvimento ágil, repensar configurações excessivas, uso de convenções entre muitas outras coisas.

Mas a espeficação JEE cobre muito mais pontos do que simplesmente a parte Web...é só dar uma olhadinha para o número de serviços que existem num application server.

Perfeito, mas já que 99% das aplicações são simples sistemas web com backend relacional não seria melhor racionalizar este esquema? É como lidamos com sistemas: primeiro implementamos o que as pessoas usam, depois o resto.

pcalcado wrote:Perfeito, mas já que 99% das aplicações são simples sistemas web com backend relacional não seria melhor racionalizar este esquema? É como lidamos com sistemas: primeiro implementamos o que as pessoas usam, depois o resto.

Já que o JPA tambem é SE (alem de EE) não seria melhor "transformar" esses 99% das aplicações em SE, deixando pro EE apenas aquelas que realmente são EEs? Ou vcs não concordam que aplicações Struts e Hibernate nem de longe são EEs?

This message was edited 1 time. Last update was at 19/09/2007 10:38:20

pcalcado wrote:Perfeito, mas já que 99% das aplicações são simples sistemas web com backend relacional não seria melhor racionalizar este esquema? É como lidamos com sistemas: primeiro implementamos o que as pessoas usam, depois o resto.

De onde tirou essa informação ? Pode até ser maior o marketshare, mas não é tão abrupto, ou você não conhece nada de Telecom.

Mensageria, área do luca e por aí vai....

A especificação é densa, pois cobre muitos pontos, talvez fosse melhor ter uma divisão na mesma como JEE Light - somente Web - área que o tomcat sempre cobriu e o resto ... aí sim, pois poderíamos pensar em simplificar ao máximo essa parte.

PS: Por essas e outras, estou indo pro grails ...

Bom, como o pcalcado comentou, acho que eles deveriam fazer o que acho que todos concordam que é inteligente:
tornar 90% do trabalho fácil, e os outros 10% possíveis
diferente do que acontece hoje, que é tornar os 10% muito fáceis, mas os outros 90% muito mais difíceis do que o necessário.

Respondendo a pergunta inicial ...
Acho que o que vai acontecer (como também ja foi mencionado aqui), é que a especificação vai pegar boas idéias de todas as alternativas disponíveis, e lançar uma versão com idéias defasadas como sempre, mas muito melhor que a atual.
Por exemplo, Hoje se eu puder trabalhar com EJB3 eu não utilizaria o Spring no projeto, no máximo o Guice só para melhorar o IoC (que esta praticamente sendo incluido no Java EE 6).
JSF 2.0 esta ficando um espetáculo
WebServices é muito mais fácil no Java EE 5 do que no Spring, mas no spring é mais flexivel, acho que poderiam incorporar a flexibilidade mantendo a forma atual como "default"
Quanto aos modulos do Java 7 e OSGI, sem comentários, neste caso acho que deveria simplesmente ser incorporado o OSGI ja que eles estão fazendo uma especificação incompleta, e na minha opinião, não tão útil na maior parte dos casos que realmente precisaria destes recursos, que provavelmente vão continuar utilizando OSGI

Quanto ao Hibernate e o JPA, não é que o JPA seja uma versão Lite do Hibernate, é que o Gaving King (é assim que escreve o nome dele?) fazia parte do Expert Group do JPA, e foi incorporando todas as idéias no Hibernate, mesmo as não aprovadas para a spec oficial (se não me engano Criteria só ficou utilizável depois do Hibernate 3, a versão que tinha no Hibernate 2 não funcionava direito e era muito lenta)

pcalcado wrote:
4) Desistir do mesmo "Novo Java EE! Agora com mais Sbrubles!!" e simplificar a casa

Concordo que seria o caminho, mas acho pouco provável que aconteça

Kenobi wrote:
As companhias têm outra velocidade de adoção e em muitas delas a versão predominante é ainda java 1.4.

O Mule por exemplo, projeto de ESB é escrito sob java 1.4 e se vc fizer em 1.3 eles até preferem ( como commiter).

Quanto a isto, a única coisa que eu tenho a dizer é: Empresas que trabalham com Java não gostam de produtividade
Isto é devido a um medo, em grande parte infundado da maior parte das empresas.
Ninguem esta dizendo apra pegar tudo o que ja tem e jogar fora, mas novos recursos e novas versões podem muito bem se beneficiar das novas versões, não fazer isto é jogar dinheiro fora, e introduzir isto em um projeto open source, é péssimo na minha opinião, mas cada doido com as suas manias

Notícias, artigos e o maior fórum brasileiro sobre Java