This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Singleton fails because of dynamic class loading

 
srinivas srinivasmeenavalli
Ranch Hand
Posts: 65
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



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
Posts: 65
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another approach could be

Refer
http://www.coderanch.com/t/325620/java/java/make-true-Singleton-even-if
 
Ravi Gupt
Greenhorn
Posts: 17
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 65
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree with you
 
Thorin Potjes
Greenhorn
Posts: 14
Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Rancher
Posts: 4660
5
Linux Mac OS X VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14
Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4660
5
Linux Mac OS X VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14
Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Pie
Posts: 20188
26
MySQL Database
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4660
5
Linux Mac OS X VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 54
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


This will create the singleton object if it doesn't exist.
 
Thorin Potjes
Greenhorn
Posts: 14
Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4660
5
Linux Mac OS X VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14
Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic