Framework que substitui Sql em java web

ORM (Object-Relational Mapping): HIBERNATE

JPQL é parte da especificação JPA que, por sua vez, é uma parte da especificação JEE.
O JPA é um conjunto de normas, assim como o JSF. Por conta disso, você vai encontrar mais de uma implementação.
As mais famosas são Hibernate e EclipseLink, mas, existem outras.
Vai do que você quer.
O Hibernate, além de atender à especificação JPA, possui uma gama própria de ferramentas para abstrair o que há de mais rotineiro na comunicação com banco de dados.

Sim sim entendo!
Mas me falaram um outro nome, não me lembro, não sei nem como chamar isso!
Mas tem a mesma função do JPQL.

rsrs, mas parece que não entendeu ainda.

Que faz a mesma coisa que o JPQL é o HQL, que é o hibernate query language.

Isso ai HQL, esse é o nome que não lembrava!
Obrigado.

O HQL está para o hibernate como a JPQL está para o JPA.
No caso, dependendo de como vc implemente, o hibernate suporta ambas, mas, isoladamente.

Se for usar Hibernate, use no padrão JPA(com JPQL), hibernate já aderiu ao padrão, não vale a pena usar os recursos antigos como Session, Criteria… engessando tudo a um ORM específico.

Na verdade vale pra qualquer ORM q for usar.

Duas coisas que nunca entendi quando se fala em ORM:

• Serve para qualquer banco de dados. Isso, ao meu ver, não é vantagem. Quantos projetos você conhece que mudaram de Oracle para SQL Server? Em quase 9 anos de desenvolvimento, nunca vi nada parecido. Ok, sei que existem projetos que são voltados a mais de um SGBD, mas, convenhamos, são projetos muitos específicos.
• Não se apegar a uma única implementação. Ora, o próprio persistence.xml demanda ser alterado quando você muda do Hibernate para EclipseLink.
  O que não muda são as anotações nas entidades, desde que, sim, sigam o padrão do JPA.

Porém, vejo que os ORMs da vida (todos, sem exceção) se limitam a projetos de médio porte, os mais comuns. Projetos maiores e menores precisam de solução mais específicas, como o JDBC puro ou o JdbcTemplate, do Spring.

Já trabalhei com um ERP que possibilitava o cliente escolher o banco que queria, pq algumas vezes ele já tinha a licença de SQL Server ou Oracle

Toda programação em Java é bem regrada a padrões, mas n quer dizer que sempre conseguirá segui-los bem a risca. E o fato de nem sempre conseguir também não quer dizer que seria bom adotar oficialmente a metodologia XGH.

É uma boa vantagem essa…
Supondo que você desenvolveu um software para varejistas utilizando o banco Oracle, e então você anuncia o seu software num site e também sai visitando as lojas para vende-lo.

Vai chegar uma hora que você vai encontrar um cliente que possui o banco SQL Server ou PostgreSQL e então você terá que reescrever uma boa parte do código…

Se você usa JPA o banco do cliente é indiferente, você só terá que alterar o arquivo persistence.xml

Nesse quesito de trocar de banco, só é vantagem se você vende softwares para empresas… se é para a sua própria empresa então não terá vantagem

Então JPQL é atualmente a mais usada com Hibernate no mercado de trabalho? Utilizando essas tecnologias meu software vai funcionar em qualquer banco de dados?

Seria arriscado dizer que é o mais usado atualmente, pois hibernate tem uma longa estrada e muitos sistemas legados usando.
Oque acontece é que recentemente migraram para os padrões do JPA e agora o recomendado seria usar nesta especificação mais “genérica”.
Se não estou enganado, foi a partir da versão 5.

Na documentação oficial tem exemplo de implementação puramente Hibernate e implementação conforme o JPA:
http://docs.jboss.org/hibernate/orm/5.3/quickstart/html_single/

O hibernate dá suporte a especificação JPA desde a primeira versão lançada após a compilação das regras deste padrão.
As mudanças na versão 5.x, em que foram depreciados métodos da API específica do hibernate é que são recentes. Estas mudanças apontam uma aderência à especificação,

Se o objetivo concreto do analista responsável não for usar mais de um banco, realmente vira overhead usar JPA/Hibernate. Ou está fugindo de aprender SQL.