Painful JPA 2.0 CriteriaQuery
JPA 2.0 offers a lot of nice features such as support for extended maps, collection mappings, automatic removal of related objects (orphan), configurable pessimistic locking and caching. But in my opinion, there are also downsides, such as the bloating CriteriaQuery which turns a simple JPQL query into a six line monster. The first time I had contact with JPA #2 was while reading IBM Developer networks “Dynamic, typesave queries in JPA 2.0″. Since there are already such great articles like “Don’t repeat the DAO” out there, I was a little confused about the focus of the article from IBM. Typesafety is great, if it’s applied in a generic way! The advantages and drawbacks of so much more code? Due raw type usage / type erasure no runtime checking for the type is possible. Secure / Deterministic refactoring may be to blame. Viewing type problems at runtime shouldn’t be an issue, since the application is being tested properly. Most IDEs offer features for String lookups during refactoring which can help with the refactoring issues. JPQL Queries tend to have a readable structure. The CriteriaQuery API looks like the opposite is the case if the query is a more complex one. In my opinion the price for such a “typesave” Query is too high; while the JPQL Query is based upon SQL and offers readability, the Criteria API looks verbose and bloated. I prefer to write good old JPQL Queries.