can we accept this code as singleton

[saikrishna cinux]

code 1
 
import java.io.*;
class Run{
private static  Run r=new Run();
private Run(){}
public static Run getRun()
{
return r;
}
}
 
 
public class Test {
public static void main(String[] args) throws Exception {
 
System.out.println(Run.getRun());
System.out.println(Run.getRun());
}
}
 
 
code 2
 
 
 
class Bed{
private Bed(){}
static Bed b=null;
static Bed getInstance(){
if(b==null){
b=new Bed();
}
return b;
} 
}
 
public class SingleTon1  {
public static void main(String a[])throws Exception
{
System.out.println(Bed.getInstance()); 
}
} 

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 ]

[Campbell Ritchie]

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]

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.

[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 bit:

static Bed getInstance()
{
   if(b==null)
      b=new Bed();
   return b;
}

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.

[saikrishna cinux]

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]

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]

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

[Stan James]

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]

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.