Posted on

Learn Hibernate core implementation.- How hibernate works

Lessons to learn from the Hibernate Core implementation

Hibernate is an open source Java persistence framework project. Perform powerful object relational mapping and query databases using HQL and SQL.
In general the widely used libraries are well designed and implemented, and it’s very interesting to learn from them some coding best practices. Let’s take a look inside the hibernate core library and discover some of its design keys.
In this post Hibernate Core is analyzed by JArchitect to go deep inside its design and implementation.

Package by Feature
Package-by-feature uses packages to reflect the feature set. It places all items related to a single feature (and only that feature) into a single directory/package. This results in packages with high cohesion and high modularity, and with minimal coupling between packages. Items that work closely together are placed next to each other.
Here’s a good article talking about packaging by feature.
Hibernate core contains many packages, each one is related to a specific feature hql, sql, and others.

Coupling
Low coupling is desirable because a change in one area of an application will require fewer changes throughout the entire application. In the long run, this could alleviate a lot of time, effort, and cost associated with modifying and adding new features to an application.
Here are three key benefits derived from using interfaces:
• An interface provides a way to define a contract that promotes reuse. If an object implements an interface then that object is to conform to a standard. An object that uses another object is called a consumer. An interface is a contract between an object and its consumer.
• An interface also provides a level of abstraction that makes programs easier to understand. Interfaces allow developers to start talking about the general way that code behaves without having to get in to a lot of detailed specifics.
• An interface enforce low coupling between components, what’s make easy to protect the interface consumer from any implementation changes in the classes implementing the interfaces.
Let’s search for all interfaces defined by Hibernate Core, for that we use CQLinq to query the code base.

from  t in Types where t.IsInterface select t

If our primary goal is to enforce low coupling, there’s a common mistake when using interfaces that could kill the utility of using them. It’s the using of the concrete classes instead of interfaces, and to explain better this problem let’s take the following example:
The class A implements the Interface IA who contains the calculate() method, the consumer class C is implemented like that

public class C

{

   ….

   public void calculate()

   {

     …..

     m_a.calculate();

     ….

    }

    A m_a;

}

The Class C instead of referencing the interface IA, it references the class A, in this case we lose the low coupling benefit, and this implementation has two major drawbacks:
• If we decide to use another implementation of IA, we must change the code of C class.
• If some methods are added to A not existing in IA, and C use them, we also lose the contract benefit of using interfaces.
C# introduced the explicit interface implementation capability to the language to ensure that a method from the IA will be never called from a reference to concrete classes, but only from a reference to the interface. This technique is very useful to protect developers from losing the benefit of using interfaces.
With JArchitect we can check this kind of mistakes using CQLinq, the idea is to search for all methods from concrete classes used directly by other methods.

from m in Methods  where m.NbMethodsCallingMe>0 && m.ParentType.IsClass

 && !m.ParentType.IsThirdParty && !m.ParentType.IsAbstract

let interfaces= m.ParentType.InterfacesImplemented

from i in interfaces where i.Methods.Where(a=>a.Name==m.Name &&

a.ParentType!=m.ParentType).Count()>0 

select new { m,m.ParentType,i }

For example the method getEntityPersister from SessionFactoryImpl which implements SessionFactoryImplementor interface is concerned by this problem.
Let’s search for methods invoking directly SessionFactoryImpl.getEntityPersister.
from m in Methods where m.IsUsing (“org.hibernate.internal.SessionFactoryImpl.getEntityPersister(String)”)
select new { m, m.NbBCInstructions }

Methods like SessionImpl.instantiate invoke directly getEntityPersister, instead of passing by interface, what break the benefit of using interfaces. Fortunately hibernate core doesn’t contains many methods having this problem.
Coupling with external jars
When external libs are used, it’s better to check if we can easily change a third party lib by another one without impacting the whole application, there are many reasons that can encourage us to change a third party lib. The other lib could:
– Have more features.
– More powerful.
– More secure.
Let’s take the example of antlr lib which used to parse the hql queries, and imagine that another parser more powerful than antlr was created, could we change the antlr by the new parser easily?
To answer this question let’s search which methods from hibernate use it directly:

from m in Methods where m.IsUsing ("antlr-2.7.7")
select new { m, m.NbBCInstructions }

And which ones used it indirectly:

from m in Projects.WithNameNotIn( "antlr-2.7.7").ChildMethods()
let depth0 = m.DepthOfIsUsing("antlr-2.7.7")
where depth0 > 1 orderby depth0
select new { m, depth0 }

Many methods use antlr directly what makes hibernate core highly coupled with it, and changing antlr with another one is not an easy task. this fact not means that we have a problem in hibernate design, but we have to be careful when using a third party lib and well check if a third party lib must be low coupled or not with the application.
Cohesion
The single responsibility principle states that a class should have one, and only one, reason to change. Such a class is said to be cohesive. A high LCOM value generally pinpoints a poorly cohesive class. There are several LCOM metrics. The LCOM takes its values in the range [0-1]. The LCOMHS (HS stands for Henderson-Sellers) takes its values in the range [0-2]. Note that the LCOMHS metric is often considered as more efficient to detect non-cohesive types.
LCOMHS value higher than 1 should be considered alarming.
In general classes more concerned by the cohesion are the classes having many methods and fields.
Let’s search for types having many methods and fields.

from t in Types where
(t.Methods.Count() > 40 || t.Fields.Count()>40) && t.IsClass
orderby t.Methods.Count() descending
select new { t, t.InstanceMethods, t.Fields,t.LCOMHS }

Only few types are concerned by this query, and for all them the LCOMHS is less than 1.
Using Annotations
Annotation-based development relieves Java developers from the pain of cumbersome configuration. And give us a powerful feature to free the source code from the boilerplate code. The resulting code is also less likely to contain bugs.
Let’s search for all annotations defined by hibernate core.
from t in Types where t.IsAnnotationClass && !t.IsThirdParty select t

Many annotations are defined, what make hibernate easy to use by developers, and the headache of configuration files is avoided.
Conclusion
Hibernate Core is a good example of open source projects to learn from, don’t hesitate to take a look inside it.

Posted on

How JRE works internally.

Interesting facts about the JRE –

Every Java developer use each day classes from the JRE, there are some most used classes like String and Array and others less known like Corba ones. In this article we will discuss about some JRE facts that can be helpful to know.
For that we will analyze the rt.jar package from the JRE 7 with JArchitect to go deep inside it , and to query its code base using CQLinq.
JRE types implementing interfaces or abstract classes
Imagine you ask two developers to declare a class which has one method doing calculation from a file as entry.
Developer A declare it like this

class A
{
public void calculate(FileStream fs)
{
}
}
And here’s the declaration of the developer B:
class B
{
public void calculate(InputStream fs)
{
}
}

Which is better and why?

To answer this question let’s take a sample code using this class
A a=new A();
FileInputStream in = new FileInputStream(“data.txt”);
a.calculate(fs);

What happen if we want to get data from ByteArrayInputStream or StringBufferInputStream?
The declaration of A don’t allow us to do that unless we change the declaration of the calculate method. However no problem occurs when we use the B class, indeed calculate take as parameter InputStream and can accept any class inheriting from InputStream.
As conclusion the B class protect from changes because it use abstract class instead of the concrete class.
Let’s search in the JRE all types that implement an interface, for that let’s execute the following CQLinq query:
from t in Types where t.IsClass && !t.IsInternal && t.NbInterfacesImplemented>0
select new { t,Interface=t.InterfacesImplemented.FirstOrDefault().Name }

And we can also search for classes inheriting from an abstract class:
from t in Types where t.IsClass && !t.IsInternal && t.BaseClasses.Where(a=>a.IsAbstract).Count()>0
select new { t,t.BaseClasses.Where(a=>a.IsAbstract).FirstOrDefault().Name }

Let’s search now for all classes implementing an interface or inheriting from an abstract class:
from t in Types where t.IsClass && !t.IsInternal && (t.NbInterfacesImplemented>0 || t.BaseClasses.Where(a=>a.IsAbstract).Count()>0)
select new { t }
And to have a better idea of classes concerned, let’s visualize the result in the metric view.
In the Metric View, the code base is represented through a Treemap. Treemapping is a method for displaying tree-structured data by using nested rectangles. The tree structure used in JArchitect treemap is the usual code hierarchy:
– Projects contains packages
– Packages contains types
– Types contains methods and fields
The treemap view provides a useful way to represent the result of CQLinq request, so we can see visually the types concerned by the request.


As we can observe many classes are concerned by the last CQLinq query, so the JRE is designed to help you to protect your code from changes by using interfaces and abstract classes, and it’s better to check as possible if a class implements an interface or inherit from an abstract class.
Immutable types
Basically, an object is immutable if its state doesn’t change once the object has been created. Consequently, a class is immutable if its instances are immutable.
There is one killer argument for using immutable objects: It dramatically simplifies concurrent programming. Think about it, why does writing proper multithreaded programming is a hard task? Because it is hard to synchronize threads accesses to resources (objects or others OS things). Why it is hard to synchronize these accesses? Because it is hard to guarantee that there won’t be race conditions between the multiple write accesses and read accesses done by multiple threads on multiple objects. What if there are no more write accesses? In other words, what if the state of the objects threads are accessing, doesn’t change? There is no more need for synchronization!
Let’s search for all JRE immutable classes
from t in Types where t.IsImmutable select t


The good news is that many classes are immutable, however String is not in the list despite of it’s the well-known immutable class of the JRE. Why this is the case?
The reason is that String contains a not final field named hash that can be modified by the public hashCode() method, but even of the existence of this field the String still immutable, and you can refer to this link to have more details why?
The JRE is designed to protect you as possible in the case of multithreading programming.
Generic types
Generics are a facility of generic programming that was added to the Java programming language in 2004 as part of J2SE 5.0. They allow a type or method to operate on objects of various types while providing compile-time type safety. A common use of this feature is when using a Java Collection that can hold objects of any type, to specify the specific type of object stored in it.
Let’s search all JRE generic types:
from t in Types where t.IsGeneric select t


To enforce type safety prefers using generic collections instead of the classic ones.

Deprecated types
A program element annotated @Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.
Let’s search for deprecated types
from t in Types where t.HasAnnotation(“java.lang.Deprecated”)
select new { t, t.NbBCInstructions }

The good news is that only a few types are deprecated, what makes the JRE cleaner.
Deprecated methods
Let’s search for deprecated methods:
from m in Methods where m.HasAnnotation(“java.lang.Deprecated”)
select new { m, m.NbBCInstructions }

Even if 437 are concerned, it represents only 0.2% of all methods. And many of them are from the awt package.
Classes with lake of cohesion
The single responsibility principle states that a class should have one, and only one, reason to change. Such a class is said to be cohesive. A high LCOM value generally pinpoints a poorly cohesive class. There are several LCOM metrics. The LCOM takes its values in the range [0-1]. The LCOMHS (HS stands for Henderson-Sellers) takes its values in the range [0-2]. Note that the LCOMHS metric is often considered as more efficient to detect non-cohesive types.
LCOMHS value higher than 1 should be considered alarming.
from t in Types where t.LCOMHS>1
select new { t,t.LCOMHS }


Only few types have this problem, and for some of them it just due to a not cleaned code like for the BootstrapServer class, which have a not used field named orb. and because its the only field the class is considered poorly cohesive.
Most complex classes
Complex classes are the more risky to maintain and evolve, let’s search for the more complex JRE classes:
(from t in Types
orderby t.BCCyclomaticComplexity descending
select new { t, t.BCCyclomaticComplexity }).Take(100)


If a class is very complex, there’s more chance that it will be less stable due to bugs generated by the complexity, and the classes using them have to protect their self by not using them directly and use instead if possible interface or abstract class.
We can improve the last CQLinq query and add two other infos: the number of types using them and a flag to know if there’s any interface or abstract class that can we use instead of the concrete classes.

(from t in Types
let HasAbtractType=t.NbInterfacesImplemented>0 || t.BaseClasses.Where(a=>a.IsAbstract).Count()>0
orderby t.BCCyclomaticComplexity descending
select new { t, t.BCCyclomaticComplexity , t.NbTypesUsingMe,HasAbtractType=HasAbtractType}).Take(100)

Many of them have an interface or abstract class, which is a good thing to protect your code from complex types.
Conclusion
The JRE classes are maybe the most used in the java world, they must be well designed and implemented, it’s a good idea to take a look inside a JRE and discover how they are implemented, it can help to have a cleaner source code.

Guest Author of article- Dane . You can find more article from this author on Dane’s blog