This week's book giveaway is in the Cloud/Virtualizaton forum.
We're giving away four copies of Mesos in Action and have Roger Ignazio on-line!
See this thread for details.
Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Requisites for Singleton pattern

 
MaheshS Kumbhar
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do we need to mark the class as final as well as throw an exception from constructor so that reflection cant create one more instance of the class?



Also we need to override clone method so that the another instance cannot be created by cloning.
Are there any more constraints that need to be used to make any class to follow singleton pattern?
 
Sunny Bhandari
Ranch Hand
Posts: 448
Eclipse IDE Firefox Browser Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) If your constructor is private, it is not visible via reflection also.
2) Your code is not thread safe (what if two threads try to get an instance and your code returns two different instances to both threads)
3) Your clone method and decision to make INSTANCE as private static is great.

Here is how I will write a singleton class:



 
Steve Luke
Bartender
Posts: 4181
21
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sunny Bhandari wrote:1) If your constructor is private, it is not visible via reflection also.
2) Your code is not thread safe (what if two threads try to get an instance and your code returns two different instances to both threads)
3) Your clone method and decision to make INSTANCE as private static is great.

1) I believe that depends on your security manager. I think you can get to private members via reflection (there are tricks for making String mutable this way).
2) Not true. He has a static inner class which instantiates the INSTANCE. This class is guaranteed by the Java Specification to be loaded just once. Which makes his code as Thread-Safe as yours, but also allows lazy loading (the INSTANCE isn't created until the getInstance() method is called, so it isn't created if it isn't needed) which yours does not.
 
Sunny Bhandari
Ranch Hand
Posts: 448
Eclipse IDE Firefox Browser Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
WOW!! That were some great addons for me.
But I always try to avoid inner classes -- No issues with inner classes but I don't feel comfortable in using them.
 
Mike Simmons
Ranch Hand
Posts: 3080
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The clone() trick is unnecessary. The normal behavior of clone() is to throw a CloneNotSupportedException, unless the class implements Cloneable. So as long as you don't implement Cloneable, there's nothing else you need to do on this one.

Steve is correct that it's often possible to access private elements using reflection, and this depends on the security manager. If no security manager has been installed, it's definitely possible. The trick is to call setAccessible(true) on the Constructor or other reflective object you're dealing with.

But most people don't bother guarding against this when making a Singleton. In general, reflection allows you to violate many of the rules of Java. If someone want's to break things using reflection, they generally can. It's up to the person using reflection to do it in a responsible manner.

Sunny, you may not like nested and inner classes, and you may not use them yourself - but you're still going to encounter them in code written by others. It's part of the language, and worth your while to understand the details.

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic