Singleton fails because of dynamic class loading

[srinivas srinivasmeenavalli]

package org.sri.design.ptrn.singleton;

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;
    }
    public static void main(String args[]){
    	Singleton instance1 = Singleton.getSingleInstance();
    	System.out.println("Instance Id="+instance1.toString());
    	
    	Singleton instance2 = Singleton.getSingleInstance();
    	System.out.println("Instance Id="+instance2.toString());
    	//dynamic class loading  
    	Class classSingleton;
		try {
			classSingleton = Class.forName("org.sri.design.ptrn.singleton.Singleton");
			Singleton instance3  = (Singleton)classSingleton.newInstance();
	    	System.out.println("Instance Id="+instance3.toString());
	    	classSingleton = Class.forName("org.sri.design.ptrn.singleton.Singleton");
			Singleton instance4  = (Singleton)classSingleton.newInstance();
	    	System.out.println("Instance Id="+instance4.toString());
	    	
	 	
		} catch (ClassNotFoundException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		catch(InstantiationException ie){
			ie.printStackTrace();
		}
		catch(IllegalAccessException iae){
			iae.printStackTrace();
		}
    }
}

out put :
Instance Id=org.sri.design.ptrn.singleton.Singleton@5b8c5b8c
Instance Id=org.sri.design.ptrn.singleton.Singleton@5b8c5b8c
Instance Id=org.sri.design.ptrn.singleton.Singleton@3a6c3a6c
Instance Id=org.sri.design.ptrn.singleton.Singleton@3b4c3b4c

I am not considering distrubuted applications. Private defualt constructor is not sufficient to make singleton.
We have to use parameterized constructor to avoid this problem for Example
private Singleton( int dummyArg){

} . in this example.What do you say ?

[srinivas srinivasmeenavalli]

Another approach could be

private Singleton(){
		if(singleInstance!= null){
			 throw new Error("Don't want any more instances");
		 }
	}

Refer
https://coderanch.com/t/325620/java/java/make-true-Singleton-even-if

[Ravi Gupt]

In your code singleton is not broken because of dynamic loading. it is broken because you loaded and created object from same class. thus allowing it to call private constructor.
Had your Class.newInstance() code was in a separate class, singleton behavior would have been intact.

-ravi

[srinivas srinivasmeenavalli]

Agree with you

[Thorin Potjes]

Furthermore, if you really want to use double checked locking, at least make singleInstance volatile.

A better method for creating a Singleton is the Statically Initialized Singleton (private final static MySingleton instance = new MySingleton()) or using enum (MySingleton.INSTANCE).

[Pat Farrell]

Actually, making the "singleInstane" volatile won't fix the problems that are inherent in double check locking. Google for "double check locking" and see (1) many articles on the problem
and (2) most of the solutions are still broken.

Furthermore, Singletons Considered Stupid, or Singletons Considered Harmful. They are bad. Don't use them.

[Thorin Potjes]

Hi Pat,

Not sure what problems you mean, but other threads will not get half instantiated objects when using volatile from Java 5; see The "Double-Checked Locking is Broken" Declaration .

I'm aware of the 'globals are evil' argumentation, but I wouldn't dismiss Singleton altogether, as it is a very simple and powerful pattern, as long as developers are aware of possible consequences.

Greetz

[Pat Farrell]

Thorin Potjes wrote: it is a very simple and powerful pattern, as long as developers are aware of possible consequences.

It is a simplistic and fatally flawed pattern. It appears simple. It is grossly misused. It is rarely justified, and even then, it is no longer simple. There are alternatives that work better and are no additional work.
Google Singletons considered stupid

[Thorin Potjes]

I agree that the pattern has many flaws, and that using a factory is a much better solution.

However, when programming you should also ask yourself 'what is likely to vary' and if you think it might, ask yourself 'how difficult is it to change this later, if it does turn out to vary'; if you try to build your code so that it can deal with any possible change, that sound a lot like YAGNI.

I wouldn't object to a Singleton class if:
- the same class can also be used in your unit tests, and
- you will not likely need more instances of the class in the future (although this could still be managed by the Singleton class), and
- you will not likely need to subclass the class in the future or use instances of other classes;

If people start using static methods as an easy way out of all that complex OO stuff, than I agree that that's misuse.

[Paul Clapham]

Pat Farrell wrote:

Thorin Potjes wrote: it is a very simple and powerful pattern, as long as developers are aware of possible consequences.

It is a simplistic and fatally flawed pattern. It appears simple. It is grossly misused. It is rarely justified, and even then, it is no longer simple. There are alternatives that work better and are no additional work.

Like in this post: Sounds Like A Singleton where the answer appears to be "Just create the object when you initialize the class and assign it to an instance variable". This is what happens when developers aren't aware of basic programming but have heard of Singletons.

[Pat Farrell]

Thorin Potjes wrote:- the same class can also be used in your unit tests

By definition, if testing class A requires class B to behave a certain way, you have weakened or broken your unit test.

The testable solution is dependency injection

[Nomaan Butt]

Method method = Singleton.class.getMethod("getSingleInstance", new Class[0]);
				 Object o = method.invoke(null, new Object[0]);
				 System.out.println((Singleton)o);

This will create the singleton object if it doesn't exist.

[Thorin Potjes]

Pat Farrell wrote:

Thorin Potjes wrote:- the same class can also be used in your unit tests

By definition, if testing class A requires class B to behave a certain way, you have weakened or broken your unit test.

The testable solution is dependency injection

Picture this scenario: I'm building a State Pattern with Context class C and State classes S1, S2 and S3. If S1, S2 and S3 themselves have no state (no instance variables), just behaviour, and they are not likely to change in the future, I might as well make Singletons of those classes (so they can be shared between multiple C instances, like a Flyweight pattern).

And yes, when making unit tests for class C, C's behaviour will depend on S1, S2 and S3. Classes don't operate in isolation, there will always be some dependency between classes (although this should be minimal).

The main point I'm tying to make here is that you should always strike a balance between applying OO principles and practicality. You cannot build your application so that it can easily incorporate any possible change, and even if you do get unexpected changes, you can always refactor your code if you have a solid set of unit tests.

[Pat Farrell]

Thorin Potjes wrote:I might as well make Singletons of those classes (so they can be shared between multiple C instances, like a Flyweight pattern).

No, either you are missing the point, or you are just being argumentative.

I and many other maintain that the Singleton pattern is grossly overused by Java programmers. This is a specific pattern and programming idiom. There is no reason to use this Singleton Pattern in your example. Just define the classes for your states and be done.

Actually, your wording is a bit strange, normally a "state class" has tons of state, the finite state machine is in a specific state when the FMS in using the state class. It is, in essence only the state. You are correct that a normal state in a FSM has no instance variables. But then, while an FSM is a wonderful and useful construct, it often is hard to express cleanly in most OO languages.

In the typical implementation of a set of state classes, each class only has one method, typically called something like transition() or fire() or event() which moves the FSM to the next state, whatever that is.

[Thorin Potjes]

Pat Farrell wrote:

Thorin Potjes wrote:I might as well make Singletons of those classes (so they can be shared between multiple C instances, like a Flyweight pattern).

No, either you are missing the point, or you are just being argumentative.

I and many other maintain that the Singleton pattern is grossly overused by Java programmers. This is a specific pattern and programming idiom. There is no reason to use this Singleton Pattern in your example. Just define the classes for your states and be done.

Actually, your wording is a bit strange, normally a "state class" has tons of state, the finite state machine is in a specific state when the FMS in using the state class. It is, in essence only the state. You are correct that a normal state in a FSM has no instance variables. But then, while an FSM is a wonderful and useful construct, it often is hard to express cleanly in most OO languages.

In the typical implementation of a set of state classes, each class only has one method, typically called something like transition() or fire() or event() which moves the FSM to the next state, whatever that is.

regarding Singleton: gross overuse: I agree; many conceptual flaws: I agree; never use it: I disagree

I agree with the confusion regarding the word 'state'; the GOF themselves use the word 'state' to refer to reference variables, as well as the conceptual 'state' in the State pattern. You could therefore say that State objects may have no state (meaning they have no reference variables). The 2 different meanings of the word 'state' in that sentence is a bit confusing.