Skip to content

New updates, new bugs

August 11, 2010

Hibernate is a mess. For sure. For dummies.

Hibernate is a very powerful software. But, a few days ago, I’ve been stuck by some bugs. In fact, I was using a old Hibernate version (something about v3.2 more or less). First bug: my enumeration was throwing an exception. More annoying, a very simple relationship @ManyToMany was failing to retrieve the correct number of lines due to a bad join. Following an advice in a forum, I’ve just added the @Fetch(SUBSELECT) to fix the issue: changing the fetching method has changed the results, it was a bug in Hibernate (or, please, explain).

Then, be careful. I’ve updated my Hibernate libraries to the last stable ones: I’ve discovered an issue with some third party libraries (the JPA ones). I’ve just removed the old one, now it works (I’ve not done full regressions tests but seems stable).

Each time, you update a third party library; you must do some regression tests because even if the new version gives you some fixes, it can give you also very bad surprises. More quickly you are using a new version; luckier you are to have issues.

This is the most annoying in the JAVA Open Source frameworks: they are based on third party libraries making the stability of your software more fragile. I have an advice: avoid updating your libraries too often because recent release is not always a stable release.

I remember another school case: the release of Struts 2.0.8 (not another version). Due to a bug during the merging by the programmers, they broke the “static” part of the web part, meaning the version was not usable. Fortunately, this day, I’ve debugged the code until I found the issue and fixed it (very easy to patch). Then, I’ve tried to find if someone else found the bug: yes, it was already fixed (but no new release available). I kept my patch working fine.

But, do you think it is better with proprietary software? Not sure. Because, depending of your vendor, you can have evasive answers or sometimes they fix the issue saying on the other hand you are not using the software correctly. From my point of view, it is always better to be able to read the code rather than expecting someone patches the software for you. in any case, if you have an issue on an opened source, you can find it: sometimes, it is easier to debug your code (and the third party open source) rather than creating a reproducible test case. Especially when you work with confidential data.

Sometimes, the bug is somewhere you do not expect. It was 10 years ago, Microsoft shipped a C/C++ compiler with an issue in the realloc() function. This is one of the most important function in the C language. I’ve tried to find the bug during several days without any success. Someone has created a test case to reproduce the bug and it has been fixed in the next service pack (basically, a simply workaround was possible). For details, see http://support.microsoft.com/kb/225099

To conclude, I believe bugs will exist for a very long time and fixing is necessary for ages and will continue. Then what can I add? Some rules:

  • Check carefully your code. Nevertheless, sometimes the bug is in the compiler (or in a framework, a third party library…)
  • Refrain to upload latest versions. A stable working framework is good enough.
  • Regression tests are very useful to evaluate new third party compatibility but are never 100% reliable.
Advertisements

From → Other

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: