Posts Tagged ‘Java’

Singleton Design Pattern- Java Tech Guy must read!

Singleton design pattern is the first design pattern I learned it many years back. In early days when someone asks me, “do you know any design pattern?” I quickly and promptly answer “I know singleton design pattern” and the question follows, “do you know anything other than singleton” and I stand stumped!

What is Singleton Design Pattern…Have a look on the below image.


A java beginner will know about singleton design pattern. At least he will think that he knows singleton pattern. The definition is even easier than Newton’s third law. Then what is special about the singleton pattern. Is it so simple and straightforward, does it even deserve an article? Do you believe that you know 100% about singleton design pattern? If you believe so and you are a beginner read through the end, there are surprises for you.

There are only two points in the definition of a singleton design pattern,

  1. There should be only one instance allowed for a class and
  2. We should allow global point of access to that single instance.

GOF says, “Ensure a class has only one instance, and provide a global point of access to it.

The key is not the problem and definition. In singleton pattern, trickier part is implementation and management of that single instance. Two points looks very simple, is it so difficult to implement it. Yes it is very difficult to ensure “single instance” rule, given the flexibility of the APIs and many flexible ways available to access an instance. Implementation is very specific to the language you are using. So the security of the single instance is specific to the language used.

Strategy for Singleton instance creation

We suppress the constructor and don’t allow even a single instance for the class. But we declare an attribute for that same class inside and create instance for that and return it. Factory design pattern can be used to create the singleton instance.

public class Singleton {

  private static Singleton singleInstance;

    private Singleton() {}

  public static Singleton getSingleInstance() {

    if (singleInstance == null) {

      synchronized (Singleton.class) {

        if (singleInstance == null) {

          singleInstance = new Singleton();




    return singleInstance;


You need to be careful with multiple threads. If you don’t synchronize the method which is going to return the instance then, there is a possibility of allowing multiple instances in a multi-threaded scenario. Do the synchronization at block level considering the performance issues. In the above example for singleton pattern, you can see that it is thread safe.

But still something is wrong in the above code…keep reading you will get to to know what is wrong in the above code.

Early and lazy instantiation in singleton pattern

The above example code is a sample for lazy instantiation for singleton design pattern. The single instance will be created at the time of first call of the getSingleInstance() method. We can also implement the same singleton design pattern in a simpler way but that would instantiate the single instance early at the time of loading the class. Following example code describes how you can instantiate early. It also takes care of the multithreading scenario.

public class Singleton {

  private static Singleton singleInstance = new Singleton();

  private Singleton() {}

  public  static Singleton getSingleInstance() {

    return singleInstance;



Singleton and Serialization

Using serialization, single instance contract of the singleton pattern can be violated. You can serialize and de-serialize and get a new instance of the same singleton class. Using java api, you can implement the below method and override the instance read from the stream. So that you can always ensure that you have single instance.

If you just write…

public class Singleton implements Serializable {


This code becomes ‘broken’ simply by adding one interface implementation. Solution for this is to override the below method:

private Object readResolve() throws ObjectStreamException{



Case When more than one instance occurs:

Following points we have to take care while creating a singleton pattern:

Case I: Multiple Singletons in Two or More Virtual Machines

When copies of the Singleton class run in multiple VMs, an instance is created for each machine. That each VM can hold its own Singleton might seem obvious but, in distributed systems such as those using EJBs, Jini, and RMI, it’s not so simple. Since intermediate layers can hide the distributed technologies, to tell where an object is really instantiated may be difficult.

Systems based on distributed technologies such as EJB, RMI, and Jini should avoid Singletons that hold state.

Case II: Multiple Singletons Simultaneously Loaded by Different Class Loaders

When two class loaders load a class, you actually have two copies of the class, and each one can have its own Singleton instance. That is particularly relevant in servlets running in certain servlet engines , where each servlet by default uses its own class loader. Two different servlets accessing a joint Singleton will, in fact, get two different objects.

Case III: Singleton Classes Destroyed by Garbage Collection, then Reloaded

When a Singleton class is garbage-collected and then reloaded, a new Singleton instance is created. Any class can be garbage-collected when no other object holds reference to the class or its instances. If no object holds a reference to the Singleton object, then the Singleton class may disappear, later to be reloaded when the Singleton is again needed. In that case, a new Singleton object will be created. Any static or instance fields saved for the object will be lost and reinitialized.

You can avoid class garbage collection in the older VMs by holding a reference to the Singleton class or object in some other object that persists for the program’s life. You can also set your VM to have no class garbage collection

Case IV: Multiple Instances Resulting from Incorrect Synchronization

One of the common Singleton implementations uses lazy initialization of the one instance. That means that the instance is not created when the class loads, but rather when it is first used. (See Listing 2.) A common mistake with that implementation is to neglect synchronization, which can lead to multiple instances of the singleton class.

// error, no synchronization on method
public static Singleton getInstance() {
if (_instance==null) {
_instance = new Singleton();

Return  _instance;

Two Singletons will be created if the constructor runs and simultaneously another thread call’s the method.

Multiple instances can be created even if you add a synchronized(this) block to the constructor call, as in Listing  below:

// Also an error, synchronization does not prevent
// two calls of constructor.
public static Singleton getInstance() {
if (_instance==null) {
synchronized (Singleton.class) {
_instance = new Singleton();
return _instance;

In the correct solution, seen in Listing below, make getInstance() a synchronized method:

// correct solution
public static synchronized Singleton getInstance() {
// . . .

Double-checked locking is another common solution but, unfortunately, it does not work, see the code below.

// Double-checked locking — don’t use
public static Singleton getInstance() {
if (_instance==null) {
synchronized (Singleton.class) {
if (_instance==null) {
_instance = new Singleton();

Case V: Multiple Singletons Arising when Someone has Sub-classed your Singleton

The Singleton Design Pattern is meant to give you control over access to the Singleton class. While I have mostly discussed the control of instantiation, other code can access your class another way: by sub classing it.

The uniqueness of the class cannot be imposed as a compile-time constraint on the subclass unless you use a private constructor. If you want to allow subclassing, for example, you might make the constructor protected. A subclass could then expose a public constructor, allowing anyone to make instances. Since an instance of a subclass is an instance of your superclass, you could find multiple instances of the Singleton.

Case VI: Copies of a Singleton Object that has Undergone Serialization and Deserialization

If you have a serialized object and deserialize it twice in different bjectOutputStreams, or with calls ObjectOutputStream.reset() between deserializations, you get two distinct objects, not two references to the same object.

We already discussed above how to avoid the situation by overriding readResolve();

Case VII: Override the Object clone method to prevent cloning

We can still be able to create a copy of the Object by cloning it using the Object’s clone method. This can be done as shown below

SingletonObjectDemo clonedObject = (SingletonObjectDemo) obj.clone();

This again violates the Singleton Design Pattern’s objective. So to deal with this we need to override the Object’s clone method which throws a CloneNotSupportedException exception.

public Object clone() throws CloneNotSupportedException {

throw new CloneNotSupportedException();


The below program shows the final Implementation of Singleton Design Pattern in java, by using all the steps mentioned above.

class SingletonClass {

private static SingletonClass singletonObject;

/** A private Constructor prevents any other class from instantiating.

*/ private SingletonClass() {

// Optional Code }

public static synchronized SingletonClass getSingletonObject() {

if (singletonObject == null) {

singletonObject = new SingletonClass();

} return singletonObject;


public Object clone() throws CloneNotSupportedException { throw new CloneNotSupportedException();



When to use Singleton class?

There is no straightforward answer to this question. A scenario which is acceptable to some will be unacceptable to others.

However, it is commonly accepted that the singleton can yield best results in a situation where various parts of an application concurrently try to access a shared resource. An example of a shared resource would be Logger, Print Spooler, etc.

The following points are suggested to be considered while designing a singleton class:

  1. Singleton classes must be memory-leak free. The instance of the singleton class is to be created once and it remains for the lifetime of the application.
  2. A real singleton class is not easily extensible.
  3. Derive the singleton class from an interface. This helps while doing unit testing (using Dependency Injection).

Don’t forget to add your comments.


Decorator Pattern in Java

Decorator Pattern



Extending an object‘s functionality can be done statically (at compile time) by using inheritance however it might be necessary to extend an object’s functionality dynamically (at runtime) as an object is used.

Consider the typical example of a graphical window. To extend the functionality of the graphical window for example by adding a frame to the window, would require extending the window class to create a FramedWindow class. To create a framed window it is necessary to create an object of the FramedWindow class. However it would be impossible to start with a plain window and to extend its functionality at runtime to become a framed window.



  • The intent of this pattern is to add additional responsibilities dynamically to an object.



The figure below shows a UML class diagram for the Decorator Pattern:
Decorator Pattern Implementation - UML Class Diagram The participants classes in the decorator pattern are:

  • Component – Interface for objects that can have responsibilities added to them dynamically.
  • ConcreteComponent – Defines an object to which additional responsibilities can be added.
  • Decorator – Maintains a reference to a Component object and defines an interface that conforms to Component’s interface.
  • Concrete Decorators – Concrete Decorators extend the functionality of the component by adding state or adding behavior.


The decorator pattern applies when there is a need to dynamically add as well as remove responsibilities to a class, and when subclassing would be impossible due to the large number of subclasses that could result.


Applicability & Examples

Example – Extending capabilities of a Graphical Window at runtime

Decorator Pattern Example - UML Class Diagram

In Graphical User Interface toolkits windows behaviors can be added dynamically by using the decorator design pattern.


  • Decoration is more convenient for adding functionalities to objects instead of entire classes at runtime. With decoration it is also possible to remove the added functionalities dynamically.
  • Decoration adds functionality to objects at runtime which would make debugging system functionality harder.

Making your class compatible with Java hash maps: overriding hashCode() and equals()

If  you have prior knowledge of hashing, then you may have an idea of how to write the hash function itself. On this page we’ll discuss the nuts and bolts you need to actually plug your hash function into a Java class and therefore use instances of that class as a hash map key. (Note that we concentrate on HashMaps here, but the points we discuss generally hold for related classes such as ConcurrentHashMap and HashSet.)

The basics: override hashCode() and equals()

Put very simply, there are two methods that a class needs to override to make objects of that class work as hash map keys:

public int hashCode();
public boolean equals(Object o);

As you might expect, the hashCode() method is where we put our hash function. Note that HashMap will not do any extra caching of the hash code. So if calculating the hash is relatively expensive (as in the case of String) it may be worth explicitly caching the hash code.

The equals() method

The equals() method must return true if the fields of the current object equal those of the object passed in, else return false. By “equal”, we generally mean that primitive fields match via the == operator, and objects are either both null or both non-null and match via the equals() method. Note two important constraints on equals():

  • if x.equals(y) returns true, then the hash codes of x and y must be identical;
  • it must be reflexive and transitive: that is, x.equals(y) must return the same value as y.equals(x), and if x.equals(y) and y.equals(z), then x.equals(z) must also be true (see below for what this actually means in real terms!).

The first of these is generally common sense given that the purpose of a hash function is to “narrow down a search” which will ultimately be performed using the equals() to perform the final check for a match. The second is more or less common sense, but it does mean, for example, that we can’t allow a null reference to equal an “empty” object. It also means, strictly speaking, that a subclass cannot add new variable comparisons to the equals() method2.


Now let’s see an example. We’ll look at a simple class that encapsulates a pair of screen coordinates. We assume that individually, the X and Y coordinates are essentially random, but that the maximum coordinate in each case will be in the order of a couple of thousand (in other words will have about 10 or 11 bits of randomness). So to make the hash code, we pick a number that is roughly halfway between these bits, then find a prime (or at worst odd) number that is close to 211. Our old favourite of 31 (=25-1) will do us fine. The equals() method is trivial, but note the convention of returning false if the object passed in isn’t of a compatible type.

public class CoordinatePair {
  private int x, y;
  public int hashCode() {
 return (x * 31) ^ y;
  public boolean equals(Object o) {
    if (o instanceof CoordinatePair) {
      CoordinatePair other = (CoordinatePair) o;
      return (x == other.x && y == other.y);
    return false;

1. I think this convention predates Java 5 generics: arguably, we really don’t expect a case where equals() will be called against an object of an incompatible type and should just apply the case an rely on the resulting runtime exception if the cast fails.
2. The problem with subclassing can be explained with a quick example. Suppose we extend Rectangle (whose equals() method effectively compares its co-ordinates and dimensions, although via the Rectangle2D base class) to make a class called ColouredRectangle, whose equals() method returns true if and only if the colours of the rectangles are identical. Now we have the problem that a plain Rectangle, if passed a ColouredRectangle to its equals() method, would return true provided the co-ordinates and dimensions were the same, discounting the colour; whereas the other way round, ColouredRectangle.equals() would always return false (because it wasn’t comparing against another ColouredRectangle).

The Java Class Loader – Base Concept

Class loading is one of the most powerful mechanisms provided by the Java Language Specification. All Java programmers should know how the class loading mechanism works and what can be done to suit their needs. By understanding the class loading mechanism you can save time that would otherwise be spent on debugging ClassNotFoundException , ClassCastException , etc.

Class Loaders

In a Java Virtual Machine (JVM), each and every class is loaded by some instance of a java.lang.ClassLoader. The ClassLoader class is located in the java.lang package and you can extend it to add your own functionality to class loading.

When a new JVM is started by java HelloWorld, the bootstrap class loader is responsible for loading key java classes like java.lang.Object and other runtime code into memory. The runtime classes are packaged inside jre/lib/rt.jar file. We cannot find the details of the bootstrap class loader in the java language specification, since this is a native implementation. For this reason the behavior of the bootstrap class loader will differ across JVM’s.

Maze Behind Class Loaders

All class loaders are of the type java.lang.ClassLoader. Other than the bootstrap class loader all class loaders have a parent class loader. These two statements are different and are important for the correct working of any class loaders written by a developer. The most important aspect is to correctly set the parent class loader. The parent class loader for any class loader is the class loader instance that loaded that class loader.

We have two ways to set the parent class loader:

public class CustomClassLoader extends ClassLoader{

public CustomClassLoader(){


public class CustomClassLoader extends ClassLoader{

public CustomClassLoader(){

The first constructor is the preferred one, because calling the method getClass() from within a constructor should be discouraged, since the object initialization will be complete only at the exit of the constructor code. Thus if the parent class loader is correctly set, whenever a class is requested out of a ClassLoader instance using loadClass(String name) method, if it cannot find the class, it should ask the parent first. If the parent cannot find the class, the findClass(String name) method is invoked. The default implementation of findClass(String name) will throw ClassNotFoundException and developers are expected to implement this method when they subclass java.lang.ClassLoader to make custom class loaders.

Inside the findClass(String name) method, the class loader needs to fetch the byte codes from some arbitrary source. The source may be a file system, a network URL, another application that can spit out byte codes on the fly, or any similar source that is capable of generating byte code compliant with the Java byte code specification. Once the byte code is retrieved, the method should call the defineClass() method, and the runtime is very particular about which instance of the ClassLoader is calling the method. Thus if two ClassLoader instances define byte codes from the same or different sources, the defined classes are different.

For example, lets say I’ve a main class called MyProgram. MyProgram is loaded by the application class loader, and it created instances of two class loaders CustomClassLoader1 and CustomClassLoader2 which are capable of finding the byte codes of another class Student from some source. This means the class definition of the Student class is not in the application class path or extension class path. In such a scenario the MyProgram class asks the custom class loaders to load the Student class, Student will be loaded and Student.class will be defined independently by both CustomClassLoader1 and CustomClassLoader2. This has some serious implications in java. In case some static initialization code is put in the Student class, and if we want this code to be executed one and only once in a JVM, the code will be executed twice in the JVM with our setup, once each when the class is separately loaded by both CustomClassLoaders. If we have two instances of Student class loaded by these CustomClassLoaders say student1 and student2, then student1 and student2 are not type-compatible. In other words,

Student student3 = (Student) student2;

will throw ClassCastException, because the JVM sees these two as separate, distinct class types, since they are defined by different ClassLoader instances.

The Need For Your Own Class loader

For those who wish to control the JVM’s class loading behavior, the developers need to write their own class loader. Let us say that we are running an application and we are making use of a class called Student. Assuming that the Student class is updated with a better version on the fly, i.e. when the application is running, and we need to make a call to the updated class. If you are wondering that the bootstrap class loader that has loaded the application will do this for you, then you are wrong. Java’s class loading behavior is such that, once it has loaded the classes, it will not reload the new class. How to overcome this issue has been the question on every developers mind. The answer is simple. Write your own class loader and then use your class loader to load the classes. When a class has been modified on the run time, then you need to create a new instance of your class loader to load the class. Remember, that once you have created a new instance of your class loader, then you should make sure that you no longer make reference to the old class loader, because when two instances of the same object is loaded by different class loaders then they are treated as incompatible types.

Writing Your Own Class loader

The solution to control class loading is to implement custom class loaders. Any custom class loader should have java.lang.ClassLoader as its direct or distant super class. Moreover you need to set the parent class loader in the constructor. Then you have to override the findClass() method. Here is an implementation of a custom class loader.

import java.util.Enumeration;
import java.util.Hashtable;
public class CustomClassLoader extends ClassLoader {
    public CustomClassLoader(){

    public Class loadClass(String className) throws ClassNotFoundException {
         return findClass(className);

    public Class findClass(String className){
        byte classByte[];
        Class result=null;
        result = (Class)classes.get(className);
        if(result != null){
            return result;

            return findSystemClass(className);
        }catch(Exception e){
           String classPath =    ((String)ClassLoader.getSystemResource(className.replace('.',File.separatorChar)+".class").getFile()).substring(1);
           classByte = loadClassData(classPath);
            result = defineClass(className,classByte,0,classByte.length,null);
            return result;
        }catch(Exception e){
            return null;

    private byte[] loadClassData(String className) throws IOException{

        File f ;
        f = new File(className);
        int size = (int)f.length();
        byte buff[] = new byte[size];
        FileInputStream fis = new FileInputStream(f);
        DataInputStream dis = new DataInputStream(fis);
        return buff;

    private Hashtable classes = new Hashtable();

Here is how to use the CustomClassLoader. 

<i>public class CustomClassLoaderTest {

     public static void main(String [] args) throws Exception{
        CustomClassLoader test = new CustomClassLoader();


Many J2EE application servers have a  hot deployment  capability, where we can reload an application with a new version of class definition, without bringing the server VM down. Such application servers make use of custom class loaders. Even if we don’t use an application server, we can create and use custom class loaders to fine-control class loading mechanisms in our Java applications. So have fun with custom loaders

%d bloggers like this: