Dodge Hibernate coding mistakes with Scertify’s code analysis – Part 2
This article is about checking Hibernate's best practices through static code analysis. 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.
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 :
|<property name="birthday" column="BIRTHDAY"/>|
This would be flagged as a violation by the rule. To correct it, one could add the “type” attribute :
|<property name="birthday" column="BIRTHDAY" type="TIMESTAMP"/>|
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.
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).
If you are interested or just curious, you can give it a try :
» See features
» Download the trial version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)