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?


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

More resources

  • 3
    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. – Shahzeb Mar 1 '12 at 23:07
  • 4
    @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. – Hauke Ingmar Schmidt Aug 3 '12 at 15:45

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.


i think you can also consider some other new framework like:

Query Dsl

Object Query

Torpedo Query

this give you a type safe and smart way to build queries, are not standard, but i'm quite sure that the next standard will be based on one of this technology.

if you want remain on the standards ignore this.


  • This has no relation to the question whether which is better and should've just been added as a comment on the original question – Adrian Legaspi Feb 7 '18 at 10:47
