This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Java in General and the fly likes To Make a HashMap as a Singleton Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "To Make a HashMap as a Singleton" Watch "To Make a HashMap as a Singleton" New topic
Author

To Make a HashMap as a Singleton

Daniel Gee
Ranch Hand

Joined: Aug 29, 2003
Posts: 202
Happy Holidays!

I have a value object that is cached on the application for frequent access. This value object ( a Java class) happens to be a HashMap. Therefore, I have something like:

In order to manage the access to this HashMap, I would like to create a singleton. Normally, I create a singleton this way:


I am confused about putting the two code snippets together - how do I make a HashMap a Singleton for accessing?
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3703
    
    5

Sounds fine to me, although if this is a J2EE environment, singletons aren't actually unique (despite the name) so you'd want to be careful of that. Also, you'd want to make get/put methods for accessing/creating the singleton synchronized unless its read only. Keep in mind, a singleton is a design pattern, not a specific implementation, so there are multiple ways to create one, some that are bad and others that are good.


My Blog: Down Home Country Coding with Scott Selikoff
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Scott Selikoff:
Sounds fine to me, although if this is a J2EE environment, singletons aren't actually unique (despite the name) so you'd want to be careful of that. Also, you'd want to make get/put methods for accessing/creating the singleton synchronized unless its read only. Keep in mind, a singleton is a design pattern, not a specific implementation, so there are multiple ways to create one, some that are bad and others that are good.


Why is a singleton "not unique in a J2EE environment"? If that is the case, then a singleton is not unique ever. Why do we say "the class loader is the universal scope, unless you're in a J2EE environment"?

The truth of the matter is that a singleton cannot exist without a formal proof that the universe is finite. By restricting the universal scope to "class loader", you are merely defining "a singleton within the scope of a class loader", not a "singleton". I could quite easily shift the scope around, for example, I might say:
"a singleton within a method" - we call that a local declaration
"a singleton within an object" - we call that a field
"a singleton within a thread" - we call that a thread local
"a singleton within a JVM" - I imagine this would require some kind of class loader registry (I've never attempted it)
"a singleton within several JVMs" - getting pretty complex now
"a singleton within all JVMs" - is the universe finite?

As you can see a "singleton" has no definition, and it doesn't take much analysis to prove its superficial existence. This is entirely beside the point that a "singleton" as the de facto definition stands (class loader scoped) is a euphemism for a requirement defect, failure to abstract appopriately, global (within the defined scope) variable. It is only ever (ab)used to update state in such a way that can be globally (class loader scoped) accessed, since many applications run under one class loader (a "nice" place to define a global scope).

Granted, talking in euphemisms is demonstrated to be a sound financial investment, and I've just bought a new car and motorbike, so I'm feeling the heat


Tony Morris
Java Q&A (FAQ, Trivia)
 
Don't get me started about those stupid light bulbs.
 
subject: To Make a HashMap as a Singleton
 
Similar Threads
Design Question - Refreshing Singletons
Singleton Factory Object
General Application Help
Duplicating a generic inner class to a singleton
compile-time type checking