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
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!
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.
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é
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á
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.
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.guj.com.br/posts/list/0/56298.java
TSS-Rod Johnson: “Java EE 6 Gets it Right”
[]s
Luca
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.
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?
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)
Concordo que seria o caminho, mas acho pouco provável que aconteça 
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
[quote]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 [/quote]
Acho que o Rails prestou um grande papel à comunidade de desenvolvimento. Muitas empresas ficaram interessadas em provisionar tal produtividade, mas ainda não podem adotar por questão de cultura, suporte, questões mais burocráticas.
Fato é que no Brasil, o Java se tornou muito forte e dificilmente um IT Manager irá aprovar a utilização de outra plataforma ou solução. Até mesmo a substituição de alguns “conhecidos frameworks” como Struts, é um parto em algumas instituições, pelo mesmo motivo.
Aqui eu acho que linguagens scripts como groovy e projetos como grails que utilizam a infrae-estrutura já conhecida das empresas como Hibernate e Spring por debaixo, pode ganhar muita visibilidade, pois todos querem o treco pronto pra ontem, mas ninguém quer pagar o preço do tempo do desenvolvimento.
É um paradoxo, que dá para ser contornado com linguagens de script, meu ponto de vista …
Depois entram outras questões no ciclo de desenvolvimento Web, Segurança , integrar um Acegi da vida, indexação e mecanismos de busca, testes … se fores fazer tudo isso usando o que tem de tradicional, um projeto Web simples realmente pode virar um parto.
Talvez 99% do que você tenha participado ou ouvido falar. De onde você tira essas estatísticas?
Vai dizer que você nunca inventou uma estatística na hora? :mrgreen:
O melhor é dizer ‘a grande maioria dos casos’, mas as vezes a gente usa ‘90%’.
Quando queremos causar impacto dizemos ‘99%’, e quando estamos obcecados '99,99999…% '. :lol: :lol: :lol:
[quote=rmarin]Vai dizer que você nunca inventou uma estatística na hora? :mrgreen:
O melhor é dizer ‘a grande maioria dos casos’, mas as vezes a gente usa ‘90%’.
Quando queremos causar impacto dizemos ‘99%’, e quando estamos obcecados '99,99999…% '. :lol: :lol: :lol:
[/quote]
Concordo com o rmarin e tambem com o shoes…
Esses “99%”, pelo que entendi, diz respeito àquelas aplicações feitas com struts e hibernate, ou até mesmo aquele framework antigo que algumas empresas continuam a manter e a se enganar com se aquilo fosse o supra sumo…
JEE tem que ser usando as “farpas” do JEE!!! Como comentário, estou entregando um projeto que rola a 1 ano só o desenvolvimento para um grande banco mundial que dispõe de uma arquitetura muito bem montada levando-se em consideração o tempo de vida do mesmo (5 anos de framework), usando Messageria, conectividade com ambientes heterogênios, LDAP e RACF juntos, JAAS, WebService e SOA “na veia” e coisas afim… Mas mesmo assim, estão pretendendo dar mais manutenção incluindo anotações nas chamadas ao legado via proxy dinâmico e seus milhoes de XMLs… po, será que eles não conhecem JCA? Será que eles não estão antenados na mudança do mercado?
Ai, lançam o JEE6, que faz até pipoca na Web mas as empresas que realmente necessitam de arquiteturas EE ficam na mesmice de sempre… alias, pouquissimas (muito poucas mesmo) são as empresas que tem em pauta a mudança para o JEE5 para os próximos 2 anos… então, daki a 2 anos, quem sabe, elas mudam para o JEE 5… daki a 4 vão pro JEE 6 perdendo tudo o que foi feito porque está tudo novo…
Acho que este é o motivo de manter o legado rodando em J2EE ainda… no bom e velho EE1.3 e EE1.4…
[quote=Kenobi][quote]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 [/quote]
Acho que o Rails prestou um grande papel à comunidade de desenvolvimento. Muitas empresas ficaram interessadas em provisionar tal produtividade, mas ainda não podem adotar por questão de cultura, suporte, questões mais burocráticas.
Fato é que no Brasil, o Java se tornou muito forte e dificilmente um IT Manager irá aprovar a utilização de outra plataforma ou solução. Até mesmo a substituição de alguns “conhecidos frameworks” como Struts, é um parto em algumas instituições, pelo mesmo motivo.
Aqui eu acho que linguagens scripts como groovy e projetos como grails que utilizam a infrae-estrutura já conhecida das empresas como Hibernate e Spring por debaixo, pode ganhar muita visibilidade, pois todos querem o treco pronto pra ontem, mas ninguém quer pagar o preço do tempo do desenvolvimento.
É um paradoxo, que dá para ser contornado com linguagens de script, meu ponto de vista …
Depois entram outras questões no ciclo de desenvolvimento Web, Segurança , integrar um Acegi da vida, indexação e mecanismos de busca, testes … se fores fazer tudo isso usando o que tem de tradicional, um projeto Web simples realmente pode virar um parto.
[/quote]
Eu não disse para todos adotarem RoR (gosto dele mas não é a solução para todas as aplicações do mundo)
Aquele post que eu linkei é uma critica a “burrice” de grande parte das empresas estarem ainda utilizando Java 1.3, muitas delas ainda nem utilizam Java EE 1.4, e nem pensam em adotar Java 5 menos ainda Java EE 5
isto é um absurdo, acho que todos concordam que não utilizar os novos recursos que trazem mais produtividade em um novo projeto na plataforma que você ja usa, é no minimo “burrice” …
Algumas delas nem permitem que um software que eles compram de alguem utilize Java 1.5 pois a única coisa que eles ja possuem nos servidores é Java 1.3.
Conheço diversos casos assim, este é o tipo de empresa que não gosta de produtividade.
PS.: desculpem por desvirtuar o tópico.