Do you like the Criteria api of JPA 2.0? Do you use it with framework? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

I'm used to work with Criteria API in Hibernate, and just watched how the Criteria in JPA 2.0 work.

What i like most in the Criteria of Hibernate is the ease we have to compose with Criterions.

The JPA Criteria seems quite heavy for me, and not as fluent as the Hibernate Criteria. One of the major benefits compared to Hibernate for me seems to be the use of the metamodel (Entity_.java classes), but still it's a bit heavy too since you have to maintain 2 classes, or add an annotation processor (though its quite easy to integrate with maven plugins)

I've read a blog on SpringSource that permits to reduce the complexity of composing with "JPA Predicates" and do a bit like with Criterions in Hibernate.

The Querydsl project seems interesting.

http://blog.springsource.com/2011/04/26/advanced-spring-data-jpa-specifications-and-querydsl/

Just wonder, for those using JPA2, are you using Cri开发者_StackOverflow社区teria API or it's a bit too heavy for you?

For those familiar with Hibernate Criteria and who now work with JPA Criteria, dowhich approach do you like the most and why?

Are you considering of using, or using, a framework like Querydsl or Spring Specifications over JPA2 for building your query predicates? Do you think these frameworks are mature enough to be adopted?

---

I can only provide a biased opinion, since I am the maintainer of Querydsl, but I think that both Querydsl and Spring Specifications are mature enough. Both provide a thin layer on top of JPA 2, Querydsl provides a fluent DSL for query construction and Spring Data patterns for DAO/Repository construction.

The expressivity of Querydsl is comparable to HQL/JPQL.

Here are a few JPA 2 Criteria queries and their Querydsl versions : http://source.mysema.com/forum/mvnforum/viewthread_thread,49

We provide fast bug fix cycles and responsive support in our forums. The Querydsl team cooperates with Spring, DataNucleus and other parties to improve the state of typesafe querying in Java.

---

No, don't like it, due to the lack of expressability and fluency in the API. Yes QueryDSL does the same in less code, and more naturally. For that reason we've taken the same route for JDO's own typesafe query API, comparing it to JPA Criteria https://datanucleus.wordpress.com/2010/11/09/jdo-typesafe-vs-jpa-criteria/

---

I use JPA criteria builder intensively. I use the metamodel, type-safe variant, but that isn't the only option. If you want to compare JPA to other frameworks, don't count the fact that you need to generate metamodel classes. You don't, for the same functionnality, only for added-on benefits. I wouldn't go back to any non-type-safe approach, though.

When you get used to it, it's quite simple to use, and still powerful.

One added benefit: it's standard. As in: multiple experts from different organizations agreed on it. The quality of the specification is certain, and it's still evolving. And you get multiple implementations (really, at least two of them being used in the most popular application servers). You don't get that if you take a random framework, which may or may not stand the proof of time.

Some examples from JPA2:

Root<Person> personRoot = query.from(Person.class);
Path firstNamePath = personRoot.get(Person_.firstName);
Predicate firstNamePredicate = criteriaBuilder.equal(firstNamePath, "Roger");
query.where(firstNamePredicate);

You could squeeze all of this to one line, but I mostly choose not to do it to get 100% clear code and 1 statement per line.

---

I use JPA2 in my projects and always found Criteria API a bit overcomplicated especially for building simple select statements with a few where conditions.

So I decided to go on using JPQL queries. Maybe the Criteria API has its strength with more complex queries (besides some other advantages).