Blog

Dodge Hibernate coding mistakes with Scertify’s code analysis – Part 2

Posted by Armel GOURIOU in Blog on May 10, 2013 with No Comments

In the post Dodge Hibernate coding mistakes with Scertify’s code analysis we presented some of our coding rules that deal with the implementation of equals and hashCode methods with Hibernate. In this article, we present other rules from our Hibernate/JPA repository.

We’re going to present 5 rules related to different topics and that aim at improving the robustness and the maintainability of your code.

Rule 1 : Hibernate Entity Does Not Define No Argument Constructor

This rule detects any Hibernate entity that does not define a no argument constructor.

Hibernate creates new instances of entities through reflexion, with the Class.newInstance() method. This method requires a no argument constructor to succeed. If an entity does not provide a no argument constructor, an Hibernate’s InstantiationException will be thrown.

Rule 2 : Always declare the type for a date

This rule detects entities’ field that are of the Java type java.util.Date but where the “type” attribute is not set. This attribute enables Hibernate to know how to map the java.util.Date to a SQL type : DATE, TIME or TIMESTAMP.

For example, let’s suppose we have an entity with a field called “birthday”. This entity is defined in an hibernate xml mapping file and the field “birthday” is defined as follow :

This would be flagged as a violation by the rule. To correct it, one could add the “type” attribute :

Rule 3 : Hibernate/XML Limit the number of class per mapping file

This rule detects hibernate mapping files that define more than one mapping. For sake of clarity and readability, one file should correspond to one entity and no more. It is possible to configure the number of mappings allowed in a file, however we recommend to use the default value : 1.

Rule 4 : JPA Entity class must not be final

This rule detects hibernate entities declared as final. This can be limiting in term of performance optimization as stated in http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/persistent-classes.html

A central feature of Hibernate, proxies, depends upon the persistent class being either non-final, or the implementation of an interface that declares all public methods.

You can persist final classes that do not implement an interface with Hibernate. You will not, however, be able to use proxies for lazy association fetching which will ultimately limit your options for performance tuning.

Rule 5 : Hibernate Composite Key Are Prohibited

This rule detects usages of the “Composite key” feature of hibernate. Composite keys complicate the code and the mappings. There can be situations where they are required, like when dealing with a legacy database. However, many teams may want to forbid their usage in new applications. This rule is there for them!

So, we’ve presented 5 rules to check various aspects of Hibernate’s best practices. What do you think of those best practices? Do you think they’re worth checking through code analysis? Please let us know in the comments!

About Scertify™ for Hibernate

Scertify™ for Hibernate is a product add-on for Scertify™. It includes a repository of 30 exclusive coding rules and best practices for Hibernate and JPA-based ORM frameworks. This rules repository works with both the Scertify Professional edition on the developers’ IDE (Eclipse), and the Scertify Enterprise edition in continuous integration (Maven and CLI).

Armel GOURIOU (See other posts)

Armel Gouriou has a Master's degree in computer science and is a huge Java addict. He originally worked for Tocea's R&D team where he took part in the development of Tocea's audit and refactoring softwares. He is now a member of the professional services team where his mission is to provide companies with solutions to tackle their technical debt.