Hibernate Pitfall : Non lazy collection not fully loaded

I recently came across a rather strange problem. I was using hibernate to load a collection eagerly. The collection has the lazy="false" set explicitly, but still I found that while there are 10 associations in the DB, I get only 3. Even more interestingly, once I remove/delete one of the loaded associations, I get the next but still the total count of associations loaded remains the same ! It seemed like hibernate was trying to optimize behind my back by loading only a few of the associated objects rather than the complete set. I had to have a non lazy collection fully loaded in to my domain object since there is no going back to the DB to get the collection.
I played with batch-size, fetching strategies and the like, but most of these don't apply to non-lazy associations. A whole day later I saw the problem...

This post should have been named "Bad developer pitfall", it was a code error on my side. The .equals() and .hashcode() methods were broken, causing many of the returned objects within the collection to be "equivalent" according to the object's own .equals(). Now they are going to be loaded in to a Set; a data structure that by definition does not contain dupes. How does java check for dupes ? by calling the .equals method. Aaahhh it all fits in now. Poor old hibernate was infact loading everything, but as soon as they were being put in to the collection, they were overwriting eachother. Now things would have been even more twisted had I been using these objects as Keys in collections, because as it turned out the hashcode()-equals() contract was intact, but with a broken equals(), you got a broken hashcode() too.

Note to self : think before scribbling out an equals() and hashcode() !

Changing themes in KDE 3 [cmd line]

For some reason, the control panel applet does not work for me to change the KDM theme nowadays. I highly suspect its started since I tried out KDE4. I use Kubuntu Hardy Heron(8.04) now; It used to work in Fiesty Fawn(7.04). anyways heres something that may work out :

In /etc/kde3/kdm/kdmrc I commented out the theme=something line. Now it obeyes the Control Center settings.

Or change the line to point to your theme; But you still need to use Cntrol Center to install the theme.

hbm2ddl not commiting on HSQLDB

Just noticed that the hbm2ddl ant task does not commit on HSQLDB. I am using hibernate 3.3 and with the sable set of hibernate-tools. It turned out to be a "change" (bug?) in Hypersonic SQL's behavior starting from 1.7.1; I'm using 1.9;
and can be fixed or worked around by telling Hibernate (not HSQL ) to shutdown.

The problem seems too be that prior to 1.7.1, hypersonic used to shutdown and flush the memory to disk if no more connections to the db existed. But now it does not do that; and the result is that by the time the hypersonic JVM terminates, it still hasn't written the schema to disk, unless you told it to do so before terminating.

Setting the property hibernate.connection.shutdown=true will make Hibernate tell HSQL db to flush after it gives up a connection.

Still Double Checks !!!

Singleton, though easy on paper, is one of the most difficult patters to implement in Java. I recenty came across this code for an "efficient thread safe singleton" in a tech forum .

public class ClassicSingleton {
private static ClassicSingleton instance = null;

private ClassicSingleton() {
// make ur constructor private to prevent the instantiation
}

public static ClassicSingleton getInstance() {
if (instance == null) {

//Allow only one thread to access
//Incase of two threads accessing exactly at same time.
//Thread 1 will get the lock and Thread 2 will wait.

synchronized (ClassicSingleton.class) {
//check one more time
//For thread 1 instance is null and it will create the object.
//When Thread 2 will enter the condition will be false as thread 1 has already created the object

if (instance == null) {
instance = new ClassicSingleton();
}
}
}

return instance;
}
}


The above code is not correct .Its exhibits an anti-pattern/ idiom commonly called "Double Checked Locking" DCL for short.The issue is that DCL is broken in java. This has to with the java memory model. Though it got revised in JDK 5.0 DCL is still not supported, even with the java.util.concurrent.* abstractions.

The first and simplest reason it does not work is that the writes that initialize the 'ClassicSingleton' object and the write to the 'instance' field can be done or perceived out of order. Thus, a thread which invokes getInstance() could see a non-null reference to a 'ClassicSingleton' object, but see the default values for fields of the 'ClassicSingleton' object, rather than the values set in the constructor. If the compiler inlines the call to the constructor, then the writes that initialize the object and the write to the 'instance' field can be freely reordered if the compiler can prove that the constructor cannot throw an exception or perform synchronization.
So the after the first thread exits and the second thread runs the second will see that the instance is not null as expected, but the intance it gets may be having its fields initialized improperly, since there is no guarantee that the constructor run has compled the writes that initializes the fields (if any).
The most saddeing fact is that this sort of re-ordering is completely legal as per the spec for the Java memory model.
Doug Lea is an authority on compiler re-orderings and has written an excellent article here http://gee.cs.oswego.edu/dl/cpj/jmm.html

As for the solution, the best way would be to synchonize the entire method(ie synchronized getInstance()), while this has the penalty that sysnchronization will be used every time the method is invoked.(While its absolutely necessary only for the first call.after that the null check would always return false)

Java System Tray Notification

After lots of attempts to display a baloon notification from the windows systray, I found this as a widget. ! Check out this page. This one uses SWT. You can also do the same from plain vanilla java swing, using the upcoming JDIC features that are being incorporated in to Mustang.
It is interesting to note that this feature which is obviously platform dependent is being incorporated in to the java.awt.* package. While that package choice is expected , considering the platform dependence of having to execute native code to achieve this, what is surprising that Mustang too stays true to the AWT architecture of having peer components. Contrary to the SWT widget set, which does not have inherent support for Tray notifications, Mustang's JDIC is really feature rich providing full flexibility when using the Tray Icon API.

Keeping it Simple

I've been working on a passtime project that includes a java client side application. Swing seemed to be the natural choice, and eventhough i had some experience with it, i decided to go the SWT way. So I got down and downloaded eclipse, ditching my favorite IntelliJ. And as expected problems galore !
Why does eclipse have to be such a pain? I kept asking myself. But in a couple of hours things started to smooth out, and i was happily jogging through my first few SWT shells. The technology sure is incredibly attrative, using the underlying OS to get the rendering work done is nothing new to java, since the AWT was based upon this idea. But the SWT design is really interesting and how they set about to do this is really great. check out this article.

The java bug

Welcome to BiteCode.
In the coming times, you'll find a welath of Java and J2EE articles here.
BiteCode is the technical counterpart of jgjoseph.blogspot.com