 <p>It is a bad idea, but if you change the <code>private</code> variable to a <code>public</code> one, you will achieve your goal. You probably should declare the variable as <code>final</code> as well to avoid surprises, but it is not strictly necessary, and doesn't make it a good idea (IMO).</p> <p>For what it is worth, there is no way to implement a singleton that doesn't involve an explicit variable to hold the instance, or an <code>enum</code>.</p> <hr> <p>Here is what Bloch has to say on the tradeoff between the public and private variable approaches:</p> <blockquote> <p>"One advantage of the factory-method approach is that it gives you the flexibility to change your mind about whether the class should be a singleton without changing its API. The factory method returns the sole instance but could easily be modified to return, say, a unique instance for each thread that invokes it. A second advantage, concerning generic types, is discussed in Item 27. Often neither of these advantages is relevant, and the final-field approach is simpler."</p> </blockquote> <p>My argument is that <em>knowing</em> that you won't need to change your mind in the future involves a degree of prescience. </p> <p>Or to put it another way, you can't <em>know</em> that: you can only predict that. And your prediction can be wrong. And if that prediction does turn out to be wrong, then you have to change every piece of code the accesses the singleton via the public variable.</p> <p>Now if your codebase is small, then the amount of code you need to change is limited. However, if your codebase is large, or if it is not all yours to change, then this this kind of of mistake can have serious consequences.</p> <p>That is why it is a bad idea.</p>