It is all a matter of where u use it

Like somebody said singleton is a good pattern for providing information which is static (like application configuration etc).
Depending on the requirement you could do with lazy initalization. If the clients are numerous and the no of hits are of a mamoth proportion then use pooling. Pooling is very scalable.
And it will be good to abstract this design decesion based on a proxy.
The proxy encapsulates the logic involved in returning the instance and all that the client does is call the getInstance() on the proxy.

singleton is a good pattern for providing information which is static (like application configuration etc).
You may have noticed that I'm not a big fan of Singleton. My biggest worry about it is that it imposes the assumption that there will only, ever, even in exceptional circumstances, even for testing, be one, real, object. If I were to cnage all the refererences to the name "Singleton" to "global", would you still feel as confident in choosing it?
You seem to casually assume in the post above that an application will only ever need one application configuration class, which everything must use and know about when it is compiled. To me, this is a dangerous assumption, and enforces a restriction which you just don't need to build in to your software.
Imagine:

You want to test a small part of your application in the absence of the rest - how do you do that if you always need the configuration global class?

You need to deploy two copies of the same application in the same VM or server, each with slightly different configurations - how do you do that if there can only be one global configuration class?

You want to reuse a part of your application code for some a new project which does its configurations differently - how do you do it if the only way your code can access configurations is through a specific global class?

Please thing real hard before casually assuming that a Singleton is ever a good choice.

To make things clear singleton never says that there will be just one instance there could be multiple depending on the load.
Secondly I am not a fan of singleton either all I was saying was to have either a singleton or a factory (if stuff differs) or a pool (of similar stuff) and abstract the creation logic by using a proxy.
I do not like singleton but it should still be very much applicable to the situation that you mentioned.
1. I always keep my application configuration in a file and have the singleton instance populated from the file when the application starts.
2. Regarding two different applications I will always have two different configurations or one base configuration and two application specific configuration and have a singleton object for each configuration.
3. Since my configuration is loaded from a file it is just a matter of changing the file for reuse.
This is how most app-servers used to initialize their environments in the start up class.
(If there is no startup class you could do it in your Servlet init)

I have been quite interested in this discussion about whether or not to use the Singleton pattern.
I have two questions.
1) What about where singletons occur in the J2SE API. For example, isn't
<pre>
public static Locale Locale.getDefault()
</pre>
a singleton? Yet we certainly can effectively unit test the Locale class, and things that use Locale objects. Or does the fact that there is a
<pre>
public static void Locale.setDefault( Locale newDefault)
</pre>
make it not a singleton?
2) What cases (in your view) are appropriate uses of the Singleton pattern? Are there any? Do you recommend tearing a chapter out of Gamma et.al. (Design Patterns)? -- I am not trying to be mean or disrespectful. But I do think that a Singleton class is useful and appropriate in many cases.
[ November 25, 2002: Message edited by: Michael Zalewski ]

Originally posted by Michael Zalewski:

1) What about where singletons occur in the J2SE API. For example, isn't
<pre>
public static Locale Locale.getDefault()
</pre>
a singleton?

No, it's not. You can have as many instances of Locale in your program as you wish. The getDefault method is just a factory method encapsulating the creation of a special instance of the class.

Originally posted by Ilja Preuss:

No, it's not. You can have as many instances of Locale in your program as you wish. The getDefault method is just a factory method encapsulating the creation of a special instance of the class.

But you can have only one instance of the default Locale, which is returned by that method (Locale.getDefault). And a factory method usually does not return instances of its own class. A good example of a factory method in the core API is List.iterator(). The specific class of the object returned by this method depends on the kind of List object on which the method is invoked. Also, factory methods usually (maybe not always) return a new object every time they are invoked. A singleton method usually returns the same object each time it is invoked.
The method <pre>public static Locale getDefault()</pre> looks an awful lot like the singleton pattern <code>public static MySingleton getInstance()</code>, doesn't it?
Isn't a singleton supposed to be a special instance of a class (only one for the entire application)? Doesn't Locale.getDefault() fit the pattern?
The same arguments which Frank Carver gave against Singleton classes can be applied against the Locale.getDefault()

• You want to test a small part of your application in the absence of the rest - how do you do that if you always need the configuration global class?
• You need to deploy two copies of the same application in the same VM or server, each with slightly different configurations - how do you do that if there can only be one global configuration class?
• You want to reuse a part of your application code for some a new project which does its configurations differently - how do you do it if the only way your code can access configurations is through a specific global class?

My answers:

• The singleton returned by Locale.getDefault() doesn't impact most unit test cases. And if you need to test it, you can always use Locale.setDefault() to set up a mock object
• If you need to deploy two applications on the same VM with different values for Locale.getDefault() -- you can't do it. By design, Locale.getDefault() returns the Locale describing the environment of the VM.
• If you want to redeploy your application with a new kind of Locale, you must do it exactly that way -- through the global class which is returned by Locale.getDefault(). There ain't no other way. You can change the system properties so that Locale.getDefault() returns the proper Locale for the redeployment.

Originally posted by Michael Zalewski:
The method <pre>public static Locale getDefault()</pre> looks an awful lot like the singleton pattern <code>public static MySingleton getInstance()</code>, doesn't it?

Syntactically, yes. Semantically? I don't think so...
getDefault() returns a *special* instance of the class, whereas getInstance() returns *the only* instance. The latter is the intent of the Singleton pattern.

The same arguments which Frank Carver gave against Singleton classes can be applied against the Locale.getDefault()

The big difference is that you can create specific Locale objects and pass them to your objects under test. You can't do that with a Singleton. (Well, you can if the object doesn't access the Singleton directly, but expects the object as a parameter. But then using a Singleton seems to be rather pointless...)

public static void Locale.setDefault( Locale newDefault) will surely disqualify it as being a singleton if this method overides the instance variable.
Like I said singleton by itself is of no great use...like many of the other patterns....you combine it with others and suddenly you see it can be quite a blessing and all its cited limitations is when you apply the pattern in places where it was not supposed to be.