Choosing which API to use would not only be a handy choice in code, but one should also think about architecture. I'll describe what I think about the two:

Architecture Considerations

The advantage of using the JPA's native Criteria API is that:

The disadvantage of using the native JPA API is:

The advantage of using the Hibernate Criteria API is that:

The disadvantage of using the Hibernate Criteria API is that:

Code Considerations

Here's how a select * from person (entity Person) will look when using the JPA criteria:

CriteriaQuery<Person> criteriaQuery = criteriaBuilder.createQuery(Person.class);
Root<Person> root = criteriaQuery.from(Person.class);
criteriaQuery.select(root); // necessário caso uma condição where seja adicionada na consulta
TypedQuery<Person> query = entityManager.createQuery(criteriaQuery);
query.getResultList();

Several lines of code to perform a simple query. As said, complexity and verbosity are unfortunately great. Here's how the same query looks using Hibernate:

Criteria criteria = session.createCriteria(Person.class);
List persons = criteria.list();

Note that the code was much smaller and simpler to run, except that there was the addition of the Hibernate code itself.

What to choose?

Some questions could be asked to decide which criteria to use:

Are there solutions for using native API?

There are frameworks on the market that work with the native JPA API and make it easier to use criteria. One of them is EasyCriteria ( link ). The same queries performed above could be done as below:

EasyCriteria<Person> easyCriteria = EasyCriteriaFactory.createQueryCriteria(entityManager, Person.class);
easyCriteria.getResultList();

The advantage of using this type of framework is that you could migrate from Hibernate to OpenJPA, for example.

Another solution would be QueryDSL that also has an interface to make it easier to query and create typed criteria (I do not know if untyped criteria works). In this case you would generate a meta model and then use QueryDSL to generate the criteria.

I will try to respond objectively, but also analyze technology choices in general terms.

About API Choices

First, the idea of vendor independence that many APIs sell is tempting but, in most cases, it hardly ever occurs. Take the case of application servers, for example. Can anyone distribute the same WAR on Tomcat, JBoss, Glassfish or Weblogic? Each contains specific features that vary immensely from one to another. On the other hand, if you completely ignore the features of your application server, you will lose the advantages of using it.

In practice, you should choose from the available options that seem to best suit your project requirements without wasting too much time on it, as it probably is not worth going into too much detail when it comes to mature and commonly used products on the market. Of course there will be wrong choices and this is a real risk, so here is very much the experience and experience of the team and the leader.

Hibernate or JPA?

Now specifically speaking of JPA and Hibernate, I can say that JPA really has made great strides, but sometimes you may need a unique Hibernate feature, such as Dynamic Queries or User Types ( Update ): Hibernate 4.3 implements the JPA 2.1 specification and has the% it is no longer necessary to use a User Type to map an Enum or non-standard type. Anyway, the important thing is the idea represented in the text.).

Which one to choose then? The answer is: neither one nor the other . You can use both APIs at the same time. As a suggestion, JPA might have preference, but the hibernate API would be used when needed. Particularly I had no trouble doing this.

Hibernate Example # 1 + JPA: Dynamic queries

Using a dynamic query does not include null fields in commands such as @Converter , for example, so the default value of the database will be used. In Hibernate this can be done through XML mapping or the annotations INSERT and @org.hibernate.annotations.Entity (in the most recent versions).

But, suppose you already have a persistence.xml and a JPA entity like below:

@javax.persistence.Entity
public class MinhaEntidade { ... }

What now? Just add the Hibernate annotation:

@org.hibernate.annotations.Entity
@org.hibernate.annotations.Entity(dynamicInsert = true)
public class MinhaEntidade { ... }

Hibernate Example # 2 + JPA: Session Access

What if I have some HQL feature that would greatly improve one of the features? No problem, just unpack the @DynamicInsert of Hibernate:

Session session = entityManager.unwrap(Session.class);

Impact of this approach

Obviously, following these examples, the implementation would be "tied" to Hibernate.

However, the impact of a change, which I believe there will always be, will be minimized to some specific functionality.

Finally, what is the real chance of needing to trade Hibernate for another JPA implementation in the near future? I'm not trying to say that Hibernate is absolutely superior, but the chances of someone needing a feature that only exists, let's suppose, in EclipseLink, and there is no available workaround, are minimal.