What is the use of the enum singleton in Java?

Question

When the Gang of four introduced the singleton pattern, they also had to explain, why not to use static class fields and method instead. The reason was: the possibility to inherit. For Java it had sense - we cannot normally inherit the class fields and methods.

Later the "Effective Java" book appeared. And we know now that the existence of reflection destroys the singularity of the singleton class with private constructor. And the only way to make a real SINGLEton is to make it as a single item of an enumeration. Nice. I had done some myself this way.

But a question remains: While we cannot inherit from enumeration, what is the use of this singleton? Why we don't use these old good static/class fields and methods?

Edit. Thanks to the @bayou.io I see that in https://softwareengineering.stackexchange.com/a/204181/44104 there is a code that can trick the enum, too, and create again two exemplars of the enum singleton. The other problems are mentioned there, too. So, there is no need to use enum instead of the usual singleton class pattern, too? BTW, all enum pluses that are mentioned here till now, work for singleton classes, too.

Answer 1

what is the use of this singleton? Why we don't use these old good static/class fields and methods?

Because enum is an object so it can not only be passed around but also implement interfaces.

Also since we are making a class, we can use the different public/private options available to all kinds of classes.

So in practice, we can make a singleton that implements an interface and then pass it around in our code and the calling code is non the wiser. We can also make the enum class package private but still pass it around to other classes in other packages that expect the interface.

If we used the static methods version, then the calling class would have to know that this object is a singleton, and our singleton class would have to be public so the other classes can see it and use it's methods.

Answer 2

There's nothing particularly wrong with the "good old fashioned singleton", enum "singletons" are just convenient - it saves you the need to muck around with boiler-plated code that looks the same in every singelton.

Answer 3

To me, a singleton makes sense wherever you want to represent something which is unique in its kind.

As an example, if we wanted to model the Sun, it could not be a normal class, because there is only one Sun. However it makes sense to make it inherit from a Star class. In this case I would opt for a static instance, with a static getter.

To clarify, here is what I'm talking about :

public class Star {
    private final String name;
    private final double density, massInKg;  

    public Star(String name, double density, double massInKg) {
        // ...
    }

    public void explode() {
       // ...
    }
}

public final class Sun extends Star {
    public static final Sun INSTANCE = new Sun();

    private Sun() { super("The shiniest of all", /**...**/, /**...**/); }
}

Sun can use all the methods of Star and define new ones. This would not be possible with an enum (extending a class, I mean).

If there is no need to model this kind of inheritance relationships, as you said, the enum becomes better suited, or at least easier and clearer. For example, if an application has a single ApplicationContext per JVM, it makes sense to have it as a singleton and it usually doesn't require to inherit from anything or to be extendable. I would then use an enum.

Note that in some languages such as Scala, there is a special keyword for singletons (object) which not only enables to easily define singletons but also completely replaces the notion of static method or field.

Answer 4

1. ENUM singletons are easy to write. It will occupy very less code, which is clean & elegant if you compare with implementation of lazy singleton with double synchronized blocks

    public enum EasySingleton{
       INSTANCE;
   }
   

2. Creation of ENUM instance is thread safe.

3. ENUM singletons handled serialization by themselves.

   conventional Singletons implementing Serializable interface are no longer remain Singleton because readObject() method always return a new instance just like constructor in Java. you can avoid that by using readResolve() method and discarding newly created instance by replacing with Singeton

   private Object readResolve(){
       return INSTANCE;
   }
   

Have a look at this article on singleton