Java : final modifier and Java memory model : Answered

In my last post I had asked a question about the visibility guarantee of the final modifier in java. Well, my colleague Alex Miller simultaneously blogged about it and beat me by answering it too.

Anyways, the answer to the question lies in the guarantee that the JMM gives for final variables. Basically it gives the guarantee that the state of the final variable (in this case the map) at the time the construction is complete is published to all threads without the need of any extra memory barrier.

More proofs and discussions can be found at Alex's blog.

Java : final modifier and Java memory model

Today while I was browsing some code, I came across something like this.

public SomeClass {

 private final LinkedHashMap map = new LinkedHashMap();

 SomeClass() {
   init();
 }

 private void init() {
   for (int i = 1; i < length ++i) {
     // do some initialization here ;
     map.put(key, value);
   }
 }

 // Some read method : Is this thread safe ?
 public Object get(Object key) {
   return map.get(key);
 }

}

The map is declared as final. Notice that the map is never mutated outside the constructor but is mutated in the constructor *after* the assignment in the init() method.


Now assuming that the object is properly constructed, i.e. the reference is not leaked until construction is complete and without making any assumption about how the reference is leaked to other threads after construction, can you tell if the get() method in the class is thread safe ? If not,why ?

I asked this question to my colleagues and I got some very interesting answers. I will post the answer and the explanation in another entry.

Eclipse 3.4 Ganymede + Subclipse on Ubuntu 8.04

I recently upgraded my eclipse installation on my Ubuntu laptop to 3.4 Well, Ubuntu 8.04 still carries eclipse 3.2 in its repositories, but you could upgrade to 3.4 by following the steps described here.

Anyways after the upgrade I found that my subclipse plugin doesn't work. Since at work in Terracotta we use eclipse+subversion I couldn't live without subclipse. Searched around the web and found that there are some compatibility issues between eclipse 3.4, subclipse and svn 1.4 which comes with ubuntu 8.04

Long story short, after searching a lot found someone claim that subclipse starts working if you have svn 1.5 installed. Found out that subversion 1.5 is available in Ubuntu Interpid which is in alpha.

These are the steps I followed to get subclipse working in eclipse 3.4 on my ubuntu 8.04

1. Uninstall the existing subversion 1.4 and all related packages. (libsvn, libsvn-java, subvertion-tools)

2. Download the following packages from Interpid repository.
   

   libneon27-gnutls_0.28.2-2_i386.deb

   libsvn1_1.5.0dfsg1-4ubuntu2_i386.deb

   libsvn-java_1.5.0dfsg1-4ubuntu2_i386.deb

   subversion_1.5.0dfsg1-4ubuntu2_i386.deb

   subversion-tools_1.5.0dfsg1-4ubuntu2_all.deb

3. Install the downloaded packages by issuing the following command.
   

sudo dpkg -i *.deb

Viola, subclipse started working with eclipse 3.4 and I am a happy man again ;)

Deadlock with a single thread in Java

The classical definition of a deadlock involves two threads at the least. The other day I was joking with my colleague that it takes talent to deadlock with a single thread. It got me thinking if it is even possible. Then I realized the following code will deadlock with just a single thread.

Thread.currentThread().join();

Like I said, it takes talent ;)