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?
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.
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.
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.
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 by:autobot
A feeble attempt to tell you about our stuff that makes us money
a bit of art, as a gift, the permaculture playing cards