Title: RE: [jdjlist] Re: Singletons and is this design ok?

Take a look at the following links. I think they explain the Singleton problem…. but not understanding all of it, I could be wrong!!!

 

J2EE Singleton

 

Double-checked locking

 

Both links come from The Java™ Specialists' Newsletter Archive, which has stuff that may even challenge JDJLIST members!

 

Regards

 

Andrew

 

-----Original Message-----
From: Greg Nudelman [mailto:[EMAIL PROTECTED]
Sent: 04 April 2003 02:11
To: jdjlist
Subject: [jdjlist] Re: Singletons and is this design ok?

 

"Helper" initializers vs. "Lazy double instantiation" for static singletons are very well explained in the "Effective Java" by J. Bloch.  I think he prefers the Helpers because of some esoteric JVM properties that only he and Gosling know intimately. I've never seen a good article on it, but I'm now reading the link below.  Looks good so far! Thanks!

:-)

Greg

-----Original Message-----
From: Rick Reumann [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 02, 2003 8:42 AM
To: jdjlist
Subject: [jdjlist] Re: Singletons and is this design ok?

 

On Wed, 2 Apr 2003 05:19:13 -0800 (PST)
Phillip DuLion <[EMAIL PROTECTED]> wrote:
 
> I'm not especially fond of "explicit" singletons.  I tend to avoid
> them whenever possible.  Rather, I've usually attached single-instance
> objects to a long-lived application object, such as servlets or other
> framework classes.  But that is simply a personal preference.
>
<snip>
> http://www.javaworld.com/javaworld/javaqa/2002-04/01-qa-0412-doublelock.html
>

You know after reading the article you posted above and your comment
about "single-instance objects," I must have been having a brain fart
because could I accomplish what I wanted with just static instances of
the Lists inside of the Store objects? It mentions in the article you
posted:

<article quote>
If the singleton you are creating is static (i.e., there will only be
one Helper created), as opposed to a property of another object (e.g.,
there will be one Helper for each Foo object, there is a simple and
elegant solution.

 

Just define the singleton as a static field in a separate class. The
semantics of Java guarantee that the field will not be initialized until
the field is referenced, and that any thread which accesses the field
will see all of the writes resulting from initializing that field.

class HelperSingleton {
  static Helper singleton = new Helper();
}
</end article quote>

So, unless I'm wrong it appears I don't need the locking code? and could
do....

//class Store

private static List someList = null;

static {
 
   someList = new ArrayList();
   someList = //populate List
}

//or I suppose I could do:
private static List someList = getList();

Would the above work? I wasn't sure what would happen if at the same
time two instances of Store were trying to be created. I know the static
portion is only executed once for an instance of a class, but I wasn't
sure what would happen if two threads were trying to making the class
for the very first time before the entire instance was created. In other
words does the JVM say only "AFTER" the entire Store class is created:

"Ok, any other classes that create a Store don't execute the static
portions."

OR, even though the full instance might not yet be created of the class,
does the JVM still know to tell others:

"Hey, I'm working on creating an instance of Store and I'm in the static
block so you can't try to make an instance until I'm done with
this static block and when I'm done with the static block you can't
enter that block even though I'm not finished making the entire
instance of Store."

I guess that later is what is happening? If that's the case then it
appears the static portions are synchronized in a sense upon the first
creation of an instance of the class?

Thanks for all your comments so far.

--
Rick Reumann

---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
http://www.sys-con.com/fusetalk

---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
http://www.sys-con.com/fusetalk

---
You are currently subscribed to jdjlist as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
http://www.sys-con.com/fusetalk

Reply via email to