I have found this article in javaworld which clarify this issue.
http://www.javaworld.com/javaworld/javatips/jw-javatip52.html
------------------------------------------------------------------------
Singletons in Java 1.0 and 1.1
All Java specifications require us to keep a reference to the singleton object, or lose it to the garbage collector. But, in pre-1.2 Java specifications, the garbage collector was not only free to collect the singleton object but also the SimpleSingleton class!. This garbage collection of an actual class is also known as "class unloading."
Actually, in Java 1.0.x class unloading wasn't implemented, so our SimpleSingleton implementation would work just fine. Unfortunately, in Java 1.1.x even system classes were allowed to be unloaded. Typical workarounds for this inadvertent unloading of the singleton class include:
Keeping a reference to the singleton as a local variable in your main() method (or the run() method for thread classes).
Keeping a reference to the singleton as an instance variable in the class in which you define your main() method (or the run() method of a thread class).
Although these techniques work, they are problematic if you use third-party libraries and can't get to the singleton (as that particular class might be an internal helper class).
------------------------------------------------------------------------
Singletons in Java 1.2
After a good bit of debate on the 'Net, combined with a number of complaints, the powers that be at Sun decided to clear up the problem by slightly modifying the Java language specification.
The new rules for determining when a class may or may not be unloaded are wonderfully simple:
All classes loaded through the local, system classloader will never be unloaded.
All classes loaded through other classloaders will be unloaded only when the classloader is unloaded.
So, for the vast majority of developers, this remedy gets rid of a relatively subtle, but annoying problem -- and we never have to lift a finger!
------------------------------------------------------------------------
Actually I had a singleton rather than a static, so I think I would need to apply previous asserts.
Cheers,
Adolfo.
From: "Malik Recoing" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Subject: Re: are static classes GC'd?
Date: Fri, 31 Jan 2003 16:32:08 +0100
Friday, January 31, 2003 4:20 PM , Adolfo Miguelez
<[EMAIL PROTECTED]> a écrit :
> I agree. But, could the hashtable be collected before since it has not
> references in the method? Or is
>
> TemplatesCache.getInstance().get("key");
>
> considered as a reference?
If you use the Sigleton D.P. as it must be, I don't see any reason that your
hashtable be collected for the durring of the VM.
The siglton does'nt need the *Class* to be static but the *instance*
attribute. So as soon as you do .getInstance(), the instance attribute of
TemplateCache is affected to a new TemplatesCache and will stay as long as
the app live if you don't don't re-affect 'instance' to another object (but
you must not).
By the way and to come back to the true subject of the list , I coded such a
cache for xslt Templates, but I don't make it a singleton as I want severals
caches for each struts module context. So the unicity of each instance is
managed via a hashtable referenced in the ServletContext by a key like
"TemplatesCaches".
Malik.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
