What to use: JPQL or Criteria API?

Question

My Java application is using JPA for object persistence. The business domain is very simple (just three classes are persistent, with 3-5 properties in each). Queries are simple as well. The question is which approach I should use: JPQL or Criteria API?

Solution 1

I'm pretty sure this has already been covered here on SO but I couldn't find the existing question. So, here is my point of view on the question:

• I find JPQL queries easier to write/read.
• I find the Criteria API nice for building dynamic queries.

Which is basically what you'll find in Hibernate: Criteria vs. HQL.

But there is one major difference between the JPA 2.0 Criteria API and the Hibernate's Criteria API that is worth mentioning: the JPA 2.0 Criteria API is a typesafe API and thus gives compile time checks, code completion, better refactoring support, etc. However, I don't find that the benefits outweighs the ease of use of JPQL.

To sum up, I would favor JPQL, except for dynamic queries (e.g. for multi criteria search features).

Related questions

• Hibernate: Criteria vs. HQL
• What are some of the real world example where JPA2 Criteria API is more preferable?

More resources

• Hibernate Querying 102 : Criteria API

Solution 2

I answered a similar question previously and I will re-post my answer here for the benefit of the community. I'm going to assume you are using an Application Server vis-a-vis my answer below.

The Criteria API exists to allow for the construction of dynamic SQL queries in a type-safe manner that prevents SQL injection. Otherwise you would be concatenating SQL strings together which is both error prone and a security risk: i.e. SQL Injection. That would be the only time you would want to use the Criteria API.

If the query remains basically the same but need only accept different parameters you should use annotated @NamedQueries which are simpler, precompiled, can be cached within the secondary cache and possibly validated during server startup.

That's basically the the rule of thumb concerning Criteria Queries versus @NamedQueries. In my experience rarely do you require the Criteria API but it is good that it exists for those rare times it is required.

Hope this helps.

Comments

[Shahzeb]

Sorry for reviving old thread but should not JPQL be avoided as much as possible.Not saying that it is bad practice to use JPQL but rather I am just saying if something can be done using Criteria then should be done with out JPQL. I am just humbly seeking more of clarification from you rather questioning your preference of JPQL over Criteria.

[Hauke Ingmar Schmidt]

@Shahzeb No, absolutely not. Don't use the criteria API for anything static - i.e. if it is possible to write the query as JPQL on compile time yoh should use JPQL. Not in the form of strings that are sprinkled around in the code, of course, those are to be avoided; but as named queries. Those are parsed at startup time and even at edit time by some IDEs.

[bebbo]

Concatenation of constant strings to create a JPQL query is no security risk. That's exactly what the CriteriaBuilder does. So what is the advantage of CriteriaBuilder, other than making the code completely unreadable and incomprehensible?