JPA 2.0 em final review! Criteria no Java EE!

Chegou tarde d+! hehe

antes tarde do que nunca!

minha duvida é se gero o metamodelo bizarro isso nao me adianta em nada em relacao a refactoring, certo?

as unicas vantagens seria ter ctrl+espaco na hora de escrever os atributos e o compilador verificando o metamodelo pra mim, isso?
alias nao eh pq a criteria usando o metamodelo compilou q ela esta correta, uma vez q meu metamodelo pode estar out-of-sync com o modelo…

e seria tão mais facil se adicionassem suporte a referencia de Method e Field na linguagem (assim como Class)!!

Não gostei mto do jeito que ficou a Criteria.

Mas espero que surta outros efeitos.

isso!

verdade! mas teoricamente a ferramenta de geracao roda a toda hora

java 8…

Mas isso não vai prejudicar a performance?

Eu achava que a ferramenta de geração fosse um “hook” (não sei o nome correto, acho que é “agent”) disponível no javac. E que uma compilação simples com alguns parâmetros a mais fosse o suficiente para gerar os metamodelos. Mas posso estar enganado, isso é correto?

Geradores de código denovo? Não fugimos exatamente disso no EJB antigo? Será que ninguém desses spec leaders aprende?

Santa tartaruga, Watson!

Mas será que vale a pena deixar o Hibernate?

Parece complicado. Tem alguma idéia de como seria?

Mauricio Linhares:

Geradores de código denovo? Não fugimos exatamente disso no EJB antigo? Será que ninguém desses spec leaders aprende?

Santa tartaruga, Watson!

eu to concordando com vc… geracao de codigo, por mais automatica que seja, nunca foi uma boa ideia.
acho q vou continuar com minhas strings na jpa2

Não gostei da geração de código. Pra mim é andar pra trás.

Vou continuar com meu Hibernate ^^

Ora, usar JPA nunca significou abandonar o Hibernate, afinal de contas se o framework implementa a especificação JPA 1.0, por que não implementaria a próxima? A não ser que você esteja falando de Session, SessionFactory e correlatos.

tnaires:

Ora, usar JPA nunca significou abandonar o Hibernate, afinal de contas se o framework implementa a especificação JPA 1.0, por que não implementaria a próxima? A não ser que você esteja falando de Session, SessionFactory e correlatos.

Mas o hibernate tem funcionalidades a mais, esse é o ponto. Alem da API um pouco diferente que pode agradar mais a alguns…

Ora, usar JPA nunca significou abandonar o Hibernate, afinal de contas se o framework implementa a especificação JPA 1.0, por que não implementaria a próxima? A não ser que você esteja falando de Session, SessionFactory e correlatos.

Vai ver ele está usando a versão anterior ao hibernate 3.

E o tal do DELETE_ORPHAN?

Beleza, Criteria no JPA agora sim ficou muito bom. Eu tinha implementado minha propria criteria para o JPA. Vou ver como ficou, e ver se deixou minha implementação e passar a usar a do JPA.

Mas o hibernate tem funcionalidades a mais, esse é o ponto. Alem da API um pouco diferente que pode agradar mais a alguns...

E se quiser usar essas funcionalidadades como por exemplo acesso a Session direta do Hibernate basta fazer um cast no seu EntitityManager usando a implementação do Hibernate:

EntitityManager em;

HibernateEntityManager ehm;

this.ehm = (HibernateEntityManager)em;

ehm = (HibernateEntityManager)em;
[/quote]

Sim Paulo, tem razao, mas esse é daqueles truques que nao deveriamos usar… Assim como pegar a Connection debaixo do EntityManager…

Aí eu vou discordar completamente. JPA tem diversas falhas e a falta de uma API de criteria é apenas a mais gritante delas, acessar o objeto do Hibernate é uma coisa completamente aceitável e normal quando você não quer fazer gambiarras bizonhas.

Mauricio Linhares:

Aí eu vou discordar completamente. JPA tem diversas falhas e a falta de uma API de criteria é apenas a mais gritante delas, acessar o objeto do Hibernate é uma coisa completamente aceitável e normal quando você não quer fazer gambiarras bizonhas.

Bem, confesso que nunca consegui fugir das anotacoes “hibernate specific” (e hints) aqui na Caelum, mas, Fabio Kung e Guilherme Silveira me corrijam se estou enganado, nunca precisamos usar a Session que esta por tras do EntityManager. Creio que isso ocorre porque nos projetos que percebemos que iriamos ter de fazer essa lambança, optamos pelo Hibernate diretamente.

Com a versao 2.0 isso deve diminuir drasticamente… ta entrando second level cache, zilhares de opcoes novas de mapeamento de colecoes e de features que so o hibernate tinha. É torcer. Mas ai quando sair o hibernate4, estaremos defasados novamente.

Ora, usar JPA nunca significou abandonar o Hibernate, afinal de contas se o framework implementa a especificação JPA 1.0, por que não implementaria a próxima? A não ser que você esteja falando de Session, SessionFactory e correlatos.

Mesmo que nao abandonasse o hibernate ele sempre tem funcionalidades a mais que a JPA. E se for para usar a JPA com o hibernate então prefiro usar o hibernate sózinho.

Nao lembro quem falou que talves eu usasse o hibernate antes do 3, mas eu uso o hibernate 3.3.

"

marcosalex:

É a velha história dos prós e contras. Muita gente defende que tem de usar somente as APIs do JPA pra camada ficar independente do framework.

Mas pelo menos nos meus projetos o risco de eu ter de mudar a camada de persistencia é quase zero. O que ganho na produtividade com o Hibernate compensa os riscos de desenvolver outra DAO

As únicas pessoas que eu vejo por aí que não estão usando o Hibernate são as acham mais fácil configurar o TopLink que vem todo num jar só ou que são obrigados a usar ferramentas Oracle. Deixar de usar uma solução comprovada como o Hibernate pra atirar no escuro no TopLink é risco demais pra ter quase nada em retorno.

E mesmo assim. Uma classe DAO bem escrita pode isolar o Hibernate e dar a liberdade para que caso mude a camada de persistencia mudar apenas ali.

É exatamente como eu faço.

Nunca usei JPA + Hibernate. Sempre optei por um ou por outro, os dois juntos nunca.

E mesmo assim. em 99,[telefone removido]% dos projetos você não precisa mudar seu mecanismo de persistência, uma vez que o Hibernate foi adotado.

Você anota suas classes usando @Entity, @Table, @Column, @Id e etc?
Você persiste seus objetos usando Session e/ou usa Criteria?

Caso você responda sim às duas perguntas, você usa sim JPA + Hibernate.

Sim. A partir das ultimas versões do hibernate eles mudaram para usarem as anotações de javax.transaction e não org.hibernate.

A unica diferença é como criamos a Session.

@tnaires
Voce só pode usar como argumento a Criteria agora no lançamento da JPA 2.0. Até semana passada isso não era um argumento válido.

Talvez ainda seja válido, pois pelo que foi exposto aqui a Criteria do JPA 2.0 será sintaticamente diferente do atual Criteria do Hibernate.

Criteria já deveria ter vindo desde o JPA 1.0, agora além de melhorar o JPA, JSF tem que vir sem XML tbm para melhorar os padrões Sun, pq se for pegar wicket ou Vraptor e Hibernate vc tem mtooooo ganho com tudo q nao tem na Spec.

Talvez ainda seja válido, pois pelo que foi exposto aqui a Criteria do JPA 2.0 será sintaticamente diferente do atual Criteria do Hibernate.

Pelo contrario… voce disse que se voce usa a Session e o Criteria voce já usa o JPA + Hibernate.

Mas voce nao podia usar o Criteria antes da versão 2.0 da JPA. Isso que eu quis dizer que o seu argumento não é valido (Até lançamento da JPA 2.0)

Sergio Lopes:

Mauricio Linhares:

Geradores de código denovo? Não fugimos exatamente disso no EJB antigo? Será que ninguém desses spec leaders aprende?

Santa tartaruga, Watson!

eu to concordando com vc… geracao de codigo, por mais automatica que seja, nunca foi uma boa ideia.
acho q vou continuar com minhas strings na jpa2 :)

Felizmente discordo!

Em minha opinião geração de código está voltando com força. Até onde sei sobre as “type safe criterias”, acredito que usarão o APT para gerar código em tempo de compilação. É bem provavel que os metamodelos que deixam de ser necessários devido a refatoração serão eliminados em tempo de compilação. Isso irá causar erros de compilação e seu metamodelo estará sempre sincronizado.

Essa abordagem já vem sendo usado em algumas api’s para criar type safe queries em java.

Acho que a afirmação de que estão voltando a cometer erros do passado por utilizar geração de código um tanto exagerado. Vejam Spring Roo, MDSD, JPA 2.0, APT, oAW (xtext) entre outros. Geração de código está sendo repensado e vai trazer bons frutos, assim espero!

Thiago Senna:

Sergio Lopes:

Mauricio Linhares:

Geradores de código denovo? Não fugimos exatamente disso no EJB antigo? Será que ninguém desses spec leaders aprende?

Santa tartaruga, Watson!

eu to concordando com vc… geracao de codigo, por mais automatica que seja, nunca foi uma boa ideia.
acho q vou continuar com minhas strings na jpa2 :)

Felizmente discordo!

Em minha opinião geração de código está voltando com força. Até onde sei sobre as “type safe criterias”, acredito que usarão o APT para gerar código em tempo de compilação. É bem provavel que os metamodelos que deixam de ser necessários devido a refatoração serão eliminados em tempo de compilação. Isso irá causar erros de compilação e seu metamodelo estará sempre sincronizado.

Essa abordagem já vem sendo usado em algumas api’s para criar type safe queries em java.

Acho que a afirmação de que estão voltando a cometer erros do passado por utilizar geração de código um tanto exagerado. Vejam Spring Roo, MDSD, JPA 2.0, APT, oAW (xtext) entre outros. Geração de código está sendo repensado e vai trazer bons frutos, assim espero! ;)

Tenho que concordar com o Senna, ele me provou que a geração de código dependendo muito do contexto do projeto vale a pena, mas essa idéia na comunidade em geral não está muito madura, mas não acho ruim a geração de códigos.

Eu falei que, se você usa annotations e usa o Session, Criteria ( do Hibernate ) e correlatos, você usa Hibernate + JPA.

Ahh sim…

miss…

Apesar que de certa forma a JPA foi baseada no Hibernate então voce sempre esteve usando o Hibernate.

Em primeiro lugar, Paulo obrigado pela citação.

É normal que toda mudança gere receio. Eu ainda estou digerindo as apresentadas na terceira edição do Falando em Java.

Preciso ler o post do King novamente e o post da Linda para me posicionar a respeito. Pretendo fazer isso neste fds.

Bem pessoal,

Pelo pouco que usei o JPA eu vi que ele possui um grande potencial. O que mais gostei nele é a possibilidade de pode trocar a implementação de persistência, pode usar tanto Hibernate, TopLink ou qualquer outro framework similar. Eu sempre gostei do Hibernate. Usando JPA não estarei deixando de usar ele.

Sim Paulo, tem razao, mas esse é daqueles truques que nao deveriamos usar... Assim como pegar a Connection debaixo do EntityManager...

Aí eu vou discordar completamente. JPA tem diversas falhas e a falta de uma API de criteria é apenas a mais gritante delas, acessar o objeto do Hibernate é uma coisa completamente aceitável e normal quando você não quer fazer gambiarras bizonhas.

Usar o mecanismo para acessar os objetos do hibernate como mostrado abaixo. Acho que também e completamente aceitavel desde que você implemente uma interface para encapsular este uso.

EntitityManager em;  
     
 HibernateEntityManager ehm;  
    
 this.ehm = (HibernateEntityManager)em;

"