wood burning stoves 2.0*
The moose likes Java in General and the fly likes can we accept this code as singleton Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "can we accept this code as singleton" Watch "can we accept this code as singleton" New topic
Author

can we accept this code as singleton

saikrishna cinux
Ranch Hand

Joined: Apr 16, 2005
Posts: 689


can any one suggest me which si the correct code for singleton pattern

[ fixed [code] tag - Jim ]
[ June 04, 2006: Message edited by: Jim Yingst ]

A = HARDWORK B = LUCK/FATE If C=(A+B) then C=SUCCESSFUL IN LIFE else C=FAILURE IN LIFE
SCJP 1.4
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38491
    
  23
Difficult to tell without code tags, and just doing it from memory, but I think "B".

You ought to synchronize the getInstance method, otherwise two threads accessing it simultaneously can get different instance.
There is a long discussion in Shalloway and Trott which is reviewed in the BunkHouse Books section about the Singleton, and they say you have to take special precautions about synchronizing a Singleton in Java, but I can't remember the full details.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
There is no such thing as a singleton. There is only such thing as a "singleton" within a defined context. Many Java developers erroneously believe that a class loader encapsulates the entire universe(s?). Once you define the context (typically a class loader), then and only then can you talk about a singleton. One might shift the context around - greater or lesser - and talk about the notion of a "singleton".

For example, a local declaration is a singleton within its scope. Likewise, an instance shared among many class loaders in different VMs in different positions in spacetime may be referred to as a singleton (within the context of those VMs). You can shift the boundaries around whichever way you like - the arbitrarily chosen "class loader" to somehow mean "everything there ever was" is based on some misconceptions (which are based on even more misconceptions, etc.) posed by demigods (read: book authors) many years ago.


Tony Morris
Java Q&A (FAQ, Trivia)
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I prefer the first style. There is a caveat that it creates an instance the first time the class is referenced, whether you really meant to get a instance or not, but this has never (yet) been an important thing to me.

This bit:

is not thread safe. That means two threads calling this code at the same time might get two different instances, which is not what you want. Attempts to make it thread safe with synchronized blocks are common in older references - even Sun's - but they flat don't work. Synchronize the whole method to make it safe.

Tony's point, boiled down, is that you can't reliably force one instance per JVM with this code. Instead you'll get one instance per ClassLoader. Simple standalone apps work fine with a single ClassLoader for all the application code, but many frameworks and containers like Servlet and EJB containers have complex families of ClassLoaders. If it's mission critical to really have only one instance in those environments, things get pretty tricky.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
saikrishna cinux
Ranch Hand

Joined: Apr 16, 2005
Posts: 689
so u mean in servlets and ejb's the containers use their own classloader for laoding the lcassses at runtime..
what ever... the class loader must create only one instance as we are also keeping synchrinized modifier to getInstance method

so it must surely create only one object

am i right
?
:roll:
saikrishna cinux
Ranch Hand

Joined: Apr 16, 2005
Posts: 689
actuall the first code clearly copies the Runtime class
because Runtime class has got private constructor and also it allows the user to create an instance uysing the static method i dont know why Runtime class doesn't allow the user to create an object directly..
Ganesh Gowtham
Ranch Hand

Joined: Mar 30, 2005
Posts: 225

hi saikrishna ..

we need to use sysnchronised to the getInsatnce() , to avoid multi threads accessing the ur class ...

we will get one instance per classloader if we use correct singleton code...

normally i heard that we want to use the same concept in the servers rather than appln they will use the JNDI concept to get instance..


Thanks, Ganesh Gowtham
http://ganesh.gowtham.googlepages.com
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I said that a bit to strongly ... you might get one per class loader. It's not that every class loader will automatically make a new one, but it could.

Applications can use new ClassLoaders as well as frameworks and containers, most commonly to alter the classpath or dynamically reload classes I'd guess. So if you have two instances of Test during the day you have little assurance that they were loaded by the same ClassLoader and they could get two different instances of Run.
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Originally posted by Stan James:
I prefer the first style. There is a caveat that it creates an instance the first time the class is referenced, whether you really meant to get a instance or not, but this has never (yet) been an important thing to me.


This seems to be a common misconception. The truth is the variable initializers and static initializer are executed when the class is initialized. A class is not necessarily initialized when it is loaded and can even be 'referenced' (depending on what you mean by that) if, for example, it was a constant variable of the class that was used.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: can we accept this code as singleton