File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes JPA Certification (OCEJPA) and the fly likes is there something worse than criteria api? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » JPA Certification (OCEJPA)
Bookmark "is there something worse than criteria api?" Watch "is there something worse than criteria api?" New topic
Forums: Object Relational Mapping JPA Certification (OCEJPA)

is there something worse than criteria api?

Sebastien French

Joined: Jan 04, 2012
Posts: 25


i'm currently studying Pro JPA 2 book and by now, I'm on the Criteria API chapter ... And OMG this way of writing query is just terribly complicated and ... definitively unreadable !!
But we have to study it (a shame because I perfectly know that I will never use such a thing ! I can't even imagine someone who discover that kind of query in a real world project with thousand of queries)

Still we have to know all of it ...

I try, when reading, to write down every methods and inheritance stuffs but I can't make it clear

Does anyone know where to find a class diagram with all important Interfaces and methods ? a kind of sum up diagram ?

And I am curious about this. Does anyone ever met the use of Criteria API on a real project ? What's the gain ?

thanks a lot
Dieter Quickfend

Joined: Aug 06, 2010
Posts: 503

When I started using the JPA Criteria API, I didn't understand why it was so complicated compared to the Hibernate one. For a simple query, it's a lot of work. However, when you end up having to create large queries that differ heavily, it ends up being quite easy to use. Especially reusing and joining parts of queries can be extremely simple. When you have to do complicated stuff using it, you really notice they put a lot of thought in it. For a tutorial, check out and . They should make it a little easier to understand.

Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
Sebastien French

Joined: Jan 04, 2012
Posts: 25

thank you for your feed back, I'll check the links you gave
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950

Yes, I have used the criteria API on a real project.

It's ugly, but it beats pasting together strings for a customized query.

Customer surveys are for companies who didn't pay proper attention to begin with.
E Armitage

Joined: Mar 17, 2012
Posts: 876
I don't like it either. It assumes that the developer is going to spend their time writing specific searches on specific tables and columns. I like to think of persistence as a done deal, no need to solve it again and again for new projects, tables even. The reliance on generated code is also a nuisance, changes in the model (yes they shouldn't be often but still) become more painful to deal with.
For most projects I use a generic search method (uses the criteria API with some reflection) that can search on any column of any type on any table. It was written and tested once, it works fine most of the time, when it doesn't work I then fall back to specific queries.
It's obviously not type safe but I cover all required search scenarios in the test cases anyway so the main type safe argument falls away. I consider that the savings I get from not having to repeat similarly structured queries for different entity names is worth it in case.
As with any API, the details of the project decide which approach should be used.
Abhay Agarwal
Ranch Hand

Joined: Feb 29, 2008
Posts: 1071

indeed .. JPA Criteria API is difficult to learn (especially without any practical experience)
James Boswell

Joined: Nov 09, 2011
Posts: 1012

Tim Holloway wrote:It's ugly, but it beats pasting together strings for a customized query.

Could not agree more Tim.
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3253
I tried to refrain from posting a reply on this topic but what the heck!

I agree with OP. On three different projects that I have worked on in the past 6 years, the following is what I have seen happening:

The project started idealistically with Hibernate(or later, JPA) with queries written in HQL/JPQL and also using Criteria API. As is usually the case in Agile methodology, no sooner did the project went into UAT, change requests started coming. Also, as is usually the case, contract developers kept rolling on/off the project. By the end on an year or so, most of the code that was written using criteria queries was replaced with pure sql queries. Why? Because the developer who got the task of modifying the code needed quite a bit of time to figure out what was the code doing. Plugging in an SQL query was the quickest way to get the job done.

It's not that the subsequent developers were not smart enough. The problem is that when a developer is working on something like JavaScript and is asked to "quickly" make a "small" change in the report, it is absolutely impossible to context switch to something as different as Criteria API. Every developer has expertise on a few things among which she can easily context switch. SQL is one of them but Criteria API is not. People learn and study SQL from college. They can't forget it even if they want to. Further, a project almost never has a developer who is 100% dedicated to writing database queries (using SQL or Criteria API or whatever). So even if you wrote a criteria query yourself and if you came back to it after 6 months, you will have to spend quite a bit of time to recollect all its nuances before you can modify it.

Wait, that's not all. Most of the time I have seen that the you need to "fine tune" the query to get the data you want. So you grab the DB Artisan/TOAD window and work out the SQL. Now, writing Criteria query that spits out the same SQL is either impossible or frustratingly time consuming.

After all, most people have a limited time allocated for work. In their mind, they are saying, "f*ck this sh*t, I am putting the same SQL in the code". So they take the faster approach. They get rid of the code that requires time to comprehend, and patch in new code with SQL that just short circuits everything.

That's still not all! I am yet to see a project that has absolutely no SQL. No matter how hard you try to avoid SQL, you will always get something for which you need to write SQL. So in every project, there will always be some kind of framework/pattern that is used to work with SQLs. There will be a "queries.xml" lying around somewhere. So you just grab that file, plant your new sql in it and see Criteria query off in your rear view mirror.

I have no intention to comment on the purity or goodness of Criteria API. I am sure it is a great thing. But it is just not practical from a TCO point of view. At least that's what I have learnt and I am never going to use it on my projects.

Enthuware - Best Mock Exams and Questions for Oracle/Sun Java Certifications
Quality Guaranteed - Pass or Full Refund!
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3253
Oh, and one more thing. IMHO, no one is going to hold it against you in an interview if you do not know criteria API. But if you can't write SQLs, you can pretty much kiss a Java developer position goodbye.
James Boswell

Joined: Nov 09, 2011
Posts: 1012

But if you can't write SQLs, you can pretty much kiss a Java developer position goodbye.

I would not completely agree with this statement. True, an experienced server-side developer working in Java will over time need to learn some SQL but there are projects where the database and data access tier are taken care of by another team. You may also be asked to work soley on the presentation tier and have zero involvement with the database. Also remember that there are an increasing number of no SQL databases emerging.
Cesar Koot

Joined: Dec 10, 2009
Posts: 3
Paul Anilprem wrote:I tried to refrain from posting a reply on this topic but what the heck!

I'm glad you replied though :-)
I agree with you, Criteria is too different from anything else to simply get a grasp on if you're not used to it (that's why we're learning for this exam, right? :-p).

But what I love about it, is that it's way easier to mock and test than those pesky sql strings. How many times I've seen change be made in the database (for example change the name of a column), only to discover an sql query to fall over in production because there's just no way to test your queries. So I agree with you that it's hard to learn and read, but if all kinds of developers start to delete Criteria code in preference of sql or jpql, that's just bad, hire someone else (someone with a JPA Certificate :-))
I agree. Here's the link:
subject: is there something worse than criteria api?
Similar Threads
JPQL: converting a certain type of dynamic query to a named and static query.
CriteriaFind Confusion
UML Diagrams and package.html
Passed SCEA Parts 2 and 3 !!!!!!!!
How to createCriteria using joins?