Not if you call the singleElement method twice, it doesn'tI would go further than Stephan and say that an enum is the preferred way to create a singleton, unless you want it mutable. Of course there is considerable doubt about whether the singleton really is a pattern or an anti‑pattern.
Aditya Soni wrote:. . . OUTPUT:1284693
It outputs the same hashcode everytime and yes it is Valid as according to singleton concept but,
. . .
this also outputs same hashcode why?
. . .
That implementation is nowhere defined. The API documentation says that is what happens typically, so it might not apply in every case. Obviously nobody is going to change that in a hurry: if it ain't broke, don't fix it.
Dave Tolls wrote:. . . The hash code is a memory location in the JVM, in the case of the Object.hashCode method.
Agree with that. I did manage to get the same hashCode from instances of different classes yesterday, so my current JVM is probably behaving as you said.
. . . there's no reason I can think of for it not to be the same. . . .
Aditya Soni wrote:
Why there is same hashcode in every method calling? or It meant to be different objects but JVM store the object to that hascode everytime?
Junilu Lacar wrote:
Again, your code does not have a singleton. You only have factory methods that produce single objects each time you call them.
Have you tested that code? There is an error in your design which will ensure that no instances are ever created.
Bin Smith wrote:. . . This ensures that only one instance of Singleton class is created.
Aditya Soni wrote:and yeah i am just gaining knowledge about Singleton Concept as it is very important perspective in interview purposes