my dog learned polymorphism*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Singleton fails because of dynamic class loading Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Singleton fails because of dynamic class loading" Watch "Singleton fails because of dynamic class loading" New topic
Author

Singleton fails because of dynamic class loading

srinivas srinivasmeenavalli
Ranch Hand

Joined: Jul 13, 2008
Posts: 65



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
Ranch Hand

Joined: Jul 13, 2008
Posts: 65
Another approach could be

Refer
http://www.coderanch.com/t/325620/java/java/make-true-Singleton-even-if
Ravi Gupt
Greenhorn

Joined: Oct 16, 2007
Posts: 17
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
Ranch Hand

Joined: Jul 13, 2008
Posts: 65
Agree with you
Thorin Potjes
Greenhorn

Joined: Aug 27, 2011
Posts: 14

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).


'Design Patterns for Java' trainer
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

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
Greenhorn

Joined: Aug 27, 2011
Posts: 14

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
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

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
Greenhorn

Joined: Aug 27, 2011
Posts: 14

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
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

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
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

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
Ranch Hand

Joined: Oct 19, 2011
Posts: 54


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

Joined: Aug 27, 2011
Posts: 14

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
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

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
Greenhorn

Joined: Aug 27, 2011
Posts: 14

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Singleton fails because of dynamic class loading
 
Similar Threads
Question regaring Singleton.
Creating SingleTON without static variables
Reflection Problem
how to make single instance of a class?
Attempt to override equals() & hashCode() - please point out error(s)!