This article describes how to use UJO objects in the ORM framework Hibernate. What may be the reason to replace traditional POJO objects by more invasive alternative? I think the main advantage is an easy processing of data results by a powerful API - however someone will appreciate the performance increase of certain types of HQL queries too.
First I would like to refute the myth that the UJO object is complicated magic. The UJO can be any object that implements the interface Ujo with four methods. There are available more implementations, but now I will describe QuickUjo contained in UJO Framework 0.91, which is characterized by ease of use and high speed value access in comparison to Java reflection. Do you ask how the QuickUjo is working? Inside the object there is only one private field type of object array with a fix length equal to the number of object properties. Because an access to the object values is available by a constant UjoProperty, so we can assign any such property index which is pointing to a one cell from the field. Now we can get the value by this UJO + UjoProperty easily and then the implementation UjoProperty takes care about the appropriate value casting. It's easy, isn't it?
A typical example of code for reading values:
String name = Person.NAME.getValue(person);
the alternative use of extended implementation QuickUjoMid:
String name = person.get(Person.NAME);
Let's compare the performance of UJO and POJO objects in an ORM framework Hibernate, however we need to know how to map UJO objects. My colleague Tomas Hampl, wrote an elegant solution based on the implementation of the interface PropertyAccessor, which is now available in UJO Framework 0.91. Due to an imperfection of Hibernate we need to implement more appropriate getters, but they are used by Hibernate only at the startup of applications. We can also write setters for our own convenience so the objects can be used as the common POJOs. Sample implementation UJO is done here.
The specification of alternative accessor in HBM file is the following:
<hibernate-mapping default-access = "org.ujoframework.hibernateSupport.UjoPropertyAccessor" ... >
If you choose annotations, use the
@org.hibernate.annotations.AccessType( "org.ujoframework.hibernateSupport.UjoPropertyAccessor" )
and locate annotations on the getters.
See the benchmark results. Eeach action contains the time ratio POJO/UJO:
|Hibernate action|| POJO [sec]
|| UJO [sec]
| SINGLE SELECT
The competent interpretation of results I leave to experts in a discussion on Hibernate rather. Description of the test environment include time values can be found here. Source code can be downloaded from the project page on SourceForge.
In conclusion, I would like to say to debunk, that the real speed increase occurs mainly in fast and well-indexed SQL queries with a reasonable degree of application logic. If the response is the slow SQL query or the result is intented to to intensive treatment so the time benefit may be lost in the context of another events. Related links: