Java Lazy initialization and Double Check Locking

According to the post at the javaworld, the double check locking is broken. I agree with the author, lets see what is double-check-locking idiom.
The below code snippet is usually used to initiate some private member variables lazily.

class SomeClass {
  private Resource resource = null;
   public Resource getResource() {
     if (resource == null)
     resource = new Resource();
     return resource;
   }
}

This is a very common use case, for example most of the time, your code might not need to use resource, so why to initiate this variable if it is too costly. Instead only initiate it when necessary.
This however will not work for multi-threaded applications, as there is a potential race condition. Two threads can see that resource is null and one thread override the resource variable initiated by another thread. Simple solution is to use Synchronized access, like

class SomeClass {
   private Resource resource = null;
   public Resource Synchronized getResource() {
     if (resource == null)
     resource = new Resource();
     return resource;
   }
}

But this is now slow because whether the resource is already being initiated or not, any calls to getReource will synchronized all the threads.
The smarter solution is to use Double Checking idiom something like this -

class SomeClass {
   private volatile Resource resource = null;
   public Resource getResource() {
     if (resource == null) {
     synchronized {
       if (resource == null)
       resource = new Resource();
     }
     }
     return resource;
   }
}

However, because of the Memory model of JAVA specification, the above mentioned code might work in one JVM but might fail at times. If you remove the volatile keyword, it is definitely broken, but even if you keep the volatile keyword, it is not certain that it will work.
So what is the solution ? The author at the javaworld mentions that we should avoid the lazy initialization and the following code -

class SomeClass {
   public static Resource resource = new Resource();
}

But the problem with this code is - whether you need or not, resource will be always initialized.

According to me, better way to use lazy initialization is to use "holder-class" idiom as explained in Effective Java by Joshua Bloch. It works like this -

class SomeClass {
   private static class FieldHolder {
     static final Resource field = new Resource();
   }
   public Resource getResource() {
     return FieldHolder.field;
   }
}

There is no synchronization, so no added cost. When the getResource method will be called for the very first time, it initiates the FieldHolder class for the very first time.

Cloud computing and the responsibility of a developer

Cloud computing is not anything new. But if we ask a developer what is that she is doing to make sure her application can take the advantages of cloud, we might not get a very definitive answer. I was also not sure of the definitive rules to be followed/adopted to develop better software to make use of cloud env.

Well, here is a very nice study guide for all of us - Building cloud-ready, multicore-friendly applications- The concepts are not new, but it is a very nice reading to understand how stateless, atomic, idempotent, parallel code can make use of cloud effectively. This is a two series paper which is a must read for developers.

Its all about the Neo - the singleton

Singleton is one of the most commonly used design pattern. However, a great deal of attention is required to make it right.
The invariant of singleton is to make sure - there is one instance of the object present always. This sounds simple and looks
like make the constructor private and have a private static final instance member variable is enough to create a singleton. But what if the object needs to be Serializable ? The moment someone makes the singleton object serializable, upon deserialization, you get another instance of it. So we need to provide readResolve() throws ObjectStreamException method to fix that.
The simple implementation of singleton is

public class SingleObject {

private static SingleObject INSTANCE = new SingleObject();
private SingleObject()
{
}
public static SingleObject getInstance() {
return INSTANCE;
}
}

This is proper but as the INSTANCE is a static field, so the instance of the Singleton object will be created always.
The other implementation is lazy initialization (anything that is lazy, pay special attention to the threading)

public class SingleObject {

private static SingleObject INSTANCE = null;
private SingleObject()
{
}
public static SingleObject getInstance() {
if (null == INSTANCE ) {
INSTANCE = new SingleObject();
}
return INSTANCE;
}
}

Looks to be okay but this one is broken in multi threaded system, if two threads calls the same getInstance method, the check-and-create pattern might produce two Instances.

One simple fix is -

public static synchronized SingleObject getInstance() {
if (null == INSTANCE ) {
INSTANCE = new SingleObject();
}
return INSTANCE;
}

but then, the penalty of getInstance calling is high now, whether the object is already created or not, always synchonization is required here and it will make the application slow. Ideally, only when object is not present, it needs to be created and hence synchronized. Instead in this case, the getInstance method is synchronized, so there is a performance penalty always
whether the object is already created or not.
The fix is little tricky and now the singleton coding becomes interesting -

public class SingleObject {

private volatile static SingleObject INSTANCE = null;
private SingleObject()
{
}
public static SingleObject getInstance() {
if (null == INSTANCE ) {
synchronized (SingleObject.class) {
if (null == INSTANCE) {
INSTANCE = new SingleObject();
}
}
}
return INSTANCE;
}
}

As we can see now, there are plenty of things to worry about, the volatile variable and the double check to ensure multiple threads work properly.

If we do not want to use synchronized at all and yet make it thread safe - use the "lazy initialization holder class" idiom as mentioned by Joshua Bloch.

public class SingleObject {

private SingleObject() {
System.out.println("It got created");
}
private static class ClassHolder {
static final SingleObject instance = new SingleObject();
}
public static SingleObject getInstance() {
return ClassHolder.instance;
}
public static void someOtherFunc() {
System.out.println("Some other func can also be static ?");
}
}

In this way, we can achieve thread safety, because for the first time, the getInstance method will be called, it will access
the class ClassHolder causing it to load and initiaze the instance variable.
This is a powerful method and can be very useful for any lazy property initialization of a class.

However, there is now an easy way to create singleton since JDK 1.5 and it is called Single value enum strategy. People who follows Joshua Block and Effective Java knows what I am talking about.

public enum SingleObjectEnum {

INSTANCE;
Public void othermethods…
}

Now, SingleObjectEnum.INSTANCE is definitely a singleton and multi-threading, serialization etc is not developers headache as it comes from JVM itself.

Think of context before Design

Anyone related to software performs some design decision or other in their daily life. Sometimes we know that we are designing or sometime while coding we take those decisions naturally/unknowingly. Point is, any constructive work will have to choose among various choices to create/design something new, software is no exception.
I have realized over the years that the choices that we make can not be bound to very hard and fast rule cause they tend to change w.r.t context. And this is why it is so interesting.

For example, if we find some list of numbers to be sorted, we can say, we shall use QuickSort. Now think that these numbers are stored in a large file of 4 GB size, can we read all the numbers in memory and perform quick sort? We probably need to split the large file in several smaller files and perfom something like a mergesort. So the context really changed the decision.

I remember one time we wrote a perl function which will read all the lines in a file and perform some operations between lines. Lets say in one line, we have the cost of journey from A to B and in other line we have cost of journey from B to A. This program will combine the both way journey cost and produce one line (out of 2) after adding the costs in both ways. It was working everywhere, suddenly one day it stopped at some places. Problem is - if the file size grows large, out-of-memory error was coming.
How did the file size grow large? This program is supposed to run every after 15 min, but at some sites, customer did not run it for a week and when they re-enabled it again, it failed....
Again, context broke the design decision we took.

Around a year back I was reading some site and it was mentioned how one of the top most architect of microsoft takes interview. It was very interesting to see that he asks "design a house" type of question. The moment candidate draws some square box on the board and mentions the specifications as 16feet long, 13 feet wide, 12 feet high living room, he is almost out ...
Why ? –
Because the candidate did not ask the "context". That house was for a giraffe and not for the interviewer. So a 12 feet high becomes too less for the animal.
A good developer will always ask these questions before writing a single line of code. If he assumes something, he would also write down the assumptions.

Agile methodology tries to solve this problem. At first, it produces a basic (you can read it as crap) version of code with loads of assumptions. Show this to the user, and give them a shock, oh my god, these assumptions are not gonna work in my env! Now we are talking, we know, it is not going to work in your env, let’s note down those assumptions on which we shall work for next 6 months and give us more money :-)

Over the years I am trying to rectify myself on this -- design something and also think of breaking that design cause either today or tomorrow it will be broken by someone else in support/field/customer. Instead they find it, its better to find the problems by the creators themselves.

JSF and PopUP

By default JSF has no support for PopUps, unless you are using any custom JSF component library like Tomahawk (http://myfaces.apache.org/tomahawk/index.html), it is tough to achieve pop ups in JSF.
Lets say we want to create a web page which shows a link and on click of that link, one popup should appear with details of the element clicked. This is a very standard requirement like on click of "username" the pop up window should display the details of the user. In JSF it becomes tough because onclick event we can fire a javascript but that is not in sync with the backend action bean.
There is however an easy solution for this problem. The solution is to do the followings
1. Create one controller and bind it to the request scope
2. On click, form a URL which will look like this "newpage.jsp?param1=val"
3. The controller should read the params passed in the URL and process accordingly, for example in this case, the param would be the name of the user and the controller should contact LDAP or backend database server to fetch details data.
The controller can get the details of the parameters passed along with the URL by using FacesContext.getCurrentInstance().getExternalContext().getRequestParameterValuesMap() - this will return the map whose key is the parameter name passed in the URL.

My Status update

wow just by looking at my blog, I am figuring out how much busy I was in last couple of months. Well, 2010 is here with lots of activity for myself. The first major change was breaking up with HP. It was a long relationship - around 7 years, found myself becoming very comfortable, so decided to leave and come to US as a consultant.
As a consultant, I am doing some pretty good work in last three month or so. I worked on JSF, worked on Webservices - Axis2 (and SwA).. its cool. I want to write about JSF 1.1 and PopUp, will post it as soon as I get some free time.

JAX-RPC and JAX-WS - how does the SOAP look?

Lets consider a method like the following –

public void purchaseOrder(String item, int quantity, String description)

When this method is serialized to SOAP packet using JAX-RPC engine, the packet looks like the below





This is called SOAP encoding. The method name is the root element under the Body tag of the soap packet. Each parameter is having type defined and the value. This type will be used by the SOAP brokers/engines to de-serialize to String or int values.

The same method needs to be written like “public void someMethod(PurchesOrder po)”
to be serialized to the similar SOAP packet using JAX-WS Document literal engine .
The same method can be left unchanged to be serialized to the similar SOAP packet using JAX-WS Document literal Wrapped (wrapped means, the parameters are wrapped inside the method name) engine .
The sample SOAP packet for JAX-WS is shown below-




In case of JAX-WS, the entire XML inside the Body is deserialized to an JavaBean following JAXB. The WSDL will contain the XSD for the PurchesOrder Bean.