7

Questions:

1) If I upgrade from Hibernate 4.x to Hibernate 5.x, can I still use the "old" Criteria Queries, or only the new Typed JPA2 Criteria Queries? Is the old one deprecated, or can I use both side by side?

2) Did I understand correctly that the new Typed Criteria forces me to create a second class for each Entity class I have, thus duplicating the number of classes? Am I supposed to create these classes by hand? If not, how? Rant: Having to duplicate classes seem bizarre, so I must be misunderstanding it somehow? Isn't that overkill and unnecessarily complicated?

Marcelo Glasberg
  • 29,013
  • 23
  • 109
  • 133

1 Answers1

12

  1. No, the old criteria API is not deprecated. Just look at the javadoc: there is no deprecation warning. But I would recommend sticking to the standard JPA API, and not using the standard JPA API mixed with the proprietary Hibernate API.

  2. No, it doesn't force you. You can still use String identifiers. But if type-safety is the goal, using the metamodel classes is strongly recommended.

Of course you don't need to generate these by hand. They're generated by an annotation processor, from your entity classes and their mapping annotations. You may find it bizarre, but it's much safer to use root.get(MyEntity_.firstName) than root.get("firstName"): a typo is detected at compilation time, and if you refactor the field to firstname, the compiler will generate an error instead of letting you use the old "firstName" string identifier.

I still find JPQL queries much simpler to write, understand and maintain though, and would only use the criteria API when a dynamic query has to be generated based on multiple... criteria. Use automated tests to check if the queries are correct. Do the same, even with the criteria queries, BTW.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • If you refactor the field to firstname, will the compiler generate an error, or will the annotation processor immediately also change `MyEntity_.firstName` to `MyEntity_.newName`, so that I DON'T get any errors? – Marcelo Glasberg Mar 06 '16 at 21:15
  • The annotation processor will change MyEntity_.firstName to MyEntity_.newName, and you'll thus get compilation errors in all the places in your code where you were using MyEntity_.firstName. – JB Nizet Mar 06 '16 at 22:43
  • 3
    Yes, of course, since the annotation processor is not doing a refactor through the IDE. Jeez I really hate this new Criteria. As you suggested, our automated tests already immediately catch any string identifier errors, so I don't see the point changing. Readability of the old Hibernate Criteria is much better and that's what matters most for us. Thanks for the info. – Marcelo Glasberg Mar 06 '16 at 22:56
  • 2
    The old Criteria classes are not deprecated but no development is going in that direction either. The [5.1 guide](http://docs.jboss.org/hibernate/orm/5.1/userguide/html_single/Hibernate_User_Guide.html#criteria) states that "Hibernate offers an older, legacy org.hibernate.Criteria API which should be considered deprecated. No feature development will target those APIs. Eventually, Hibernate-specific criteria features will be ported as extensions to the JPA javax.persistence.criteria.CriteriaQuery." – Vlad Mihalcea Mar 09 '16 at 15:23
  • 5
    In 5.2 the criteria API is deprecated http://docs.jboss.org/hibernate/orm/5.2/javadocs/org/hibernate/SharedSessionContract.html#createCriteria-java.lang.Class- – Lars Aug 25 '16 at 10:52