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.

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.


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 enforces the loose coupling between components, it protect the interface consumer from any implementation changes in the classes implementing the interfaces.

Let’s search for all the 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 the loose 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 the interfaces, and to explain better this problem let’s take as example the following case:
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()
A m_a;

The Class C instead of referencing the interface IA, it references the class A, in this case we lose the loose 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
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 as example the 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.


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 }

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.


Hibernate Core is a good example of open source projects to learn from, don’t hesitate to take a look inside it.

Comparing MFC10 to MFC9

Visual C++ 2010: MFC new features

Some years ago i thought that MFC will be obsolete, and no new features will be added, but i was wrong, VS2008 added many features and functionalities, and with VS 2010 i discovered new improvements.

So what’s new in MFC 10?
To answer to this question i tried to compare the two versions MFC 8 and MFC 10 using CppDepend.

Removed classes

Let’s begin with breaking changes and search for removed classes:


It was very strange that this class is removed , and to be sure i searched in the code source and i found it inside #ifdef ENABLE_RIBBON_LAUNCH_BUTTON statement.

The only resource i found in the web talking about this change is here , and i dont know if adding #define ENABLE_RIBBON_LAUNCH_BUTTON is suficient to compile without problem.

Added Classes


What’s the new features added by these classes?

CMFCRibbonCollector, CMFCRibbonConstructor, CMFCRibbonInfo:

When i searched in MSDN the utility of these classes , i didnt found any useful informations, so i searched for methods using CMFCRibbonInfo.


The RibbonBar class use CMFCRibbonInfo to save it to xml or load it.

CJumpList, CAppDestinations:

Jump list is a new useful Window7 feature, it adds a new way of interaction between user and application.
here’s a good article to add JumpList feature with MFC.


This class autosaves documents and restores them if an application unexpectedly exits, it’s used by Restart Manager feature, here’s an interesting article talking about it.

Let’s search for classes used by CDataRecoveryHandler:

SELECT TYPES WHERE IsDirectlyUsedBy “CDataRecoveryHandler

CDataRecoveryHandler is highly coupled with other MFC classes like CDocument, CWinApp, CWnd.

Which MFC classes use the recovery feature?

SELECT TYPES WHERE IsDirectlyUsing “CDataRecoveryHandler

So all these classes benefit of this new feature especially CDocument.

A pop-up dialog box that functions like a message box but can display additional information to the user.

here’s an interesting article talking about this feature.

CMFCVisualManagerVS2008, CMFCVisualManagerWindows7:

Gives an application the appearance of a VS2008 or Windows 7 application.


Used for touch feature.


CFolderPickerDialog class implements CFileDialog in the folder picker mode.

CXMLParser, CXMLParserCollection, CXMLParserRoot:

When i discovered these classes, i thought that is concerning xml parsing but when i searched for methods using them i discovered that only CMFCRibbonInfo use them to save or load its description to xml files.


CMFCZoomKernel, CMFCScanliner, CMFCScanlinerBitmap:
Not yet documented in MSDN, let’s discover which classes use them.

SELECT TYPES WHERE IsDirectlyUsing “CMFCZoomKernel

And we have the same result for the two other classes.

SafeInt classes:
Extends the integer primitives to help prevent integer overflow and lets you compare different types of integers.
here’s a video about using SafeInt.

After detecting which classes are added and removed, let’s discover all methods removed or added to MFC10, and which features are implemented by these methods.

Methods Removed


Almost all theses methods are not removed but only the signature is changed , and some optional parameters are added, however some methods are removed like CCommandManager::ResetAllImages or CPanelDialog::ClipPaint, and one method was renamed from CMFCRibbonBar::GetTabTrancateRatio to CMFCRibbonBar::GetTabTruncateRatio.

Methods Added

Let’s search for all methods added to MFC10


Which features are added by these new methods?

For that we will focus only in the most used classes.

Here’s the methods added for CWnd, and almost all methods added concern touch feature and touch gestures.

CFile, CStdioFile, CFileFind:
Many methods of these classes add CAtlTransactionmanager as optional parameter.

Transactional File System is a new technology first introduced in Windows Vista. It enables you to roll back operations made on the file system and registry.

Here’s a good article about this feature.


New possibilities to add item to recent file list are now available.

CDocument: Here’s the methods added by CDocument:

Two new features concern methods added : Supporting Windows Search with MFC and Rich Preview

Let’s discover the changes concerning dependency of CDocument to other MFC classes,and which additional dependencies are added in MFC10, for that Dependency Matrix can be useful, and the sign “+” in the cell representing the dependency indicate that this dependency is new.

So many dependencies are added, especially with new classes added to MFC10 like CDataRecoveryHandler,and also some other inner classes added to CDocument.

CFileDialog: Here’s the methods added by CFileDialog:

A good news is we can now customize CFileDialog by adding what we want in the dialog.

Here’s the methods added by CMDIChildWndEx

Windows7 add a new interesting features like:taskbar Tabs,Taskbar thumbnails and thumbnail previews, and almost all methods added to CMDIChildWndEx concern theses features.

Windows 7 add also some useful features like OverlayIcon and progressbar in the taskbar, and the methods added to CFrameWnd concern these features.

Almost all methods added to CWinApp concern the ApplicationRecovery support.

Other useful methods are added like CMFCControlRenderer::SmoothResize and CDrawingmanager::DrawRotated.

Methods where visibility was changed


Almost the visibility of all CMFCRibbonTab methods is changed from private to public.

But when i checked the code source the only modification in the class declaration is the adding of DECLARE_DYNAMIC(CMFCRibbonTab) , this macro include “public:” , so i wonder if this visibility changes is only a side effect of adding this macro.