The Singleton pattern has been around for quite some time, providing an instrument to limit a single instance of a class. This is great use for classes which are designed solely with this in mind. Of course it has also been an anti-pattern for just as long, either as a crutch for global state or relaxed scoping. This can lead to problems with maintainability and testability. Coupling a client class to a singleton concrete instance is a problem with extending or subclassing the singleton; additionally, mock testing of a class using a singleton forces you to also test the singleton’s behaviour. Sometimes a ‘lazy’ design relying on global state can be turned on its head to better facilitate encapsulation / polymorphism.

So why not call out all those singletons and see if they can stand on their own merit?

Enter the Google Singleton Detector http://code.google.com/p/google-singleton-detector

The Google Singleton Detector identifies global state within a java application. Along with the ”classic” singleton, they have coined terms for other forms of state as well:
The Hingleton (helper singleton) which basically makes a class a singleton by ensuring that there is only one instance of it
The Mingleton (method singleton) is a class with a static parameter-less method which returns some state (non-primitive object). More informative then useful.
The Fingleton (field singleton) is a class with one or more public static fields. Again, informative given the dependency graphing provided by the tool

The GSD examines jar/classes and produces a graphML file showing the above -ingletons and all dependent classes. The tool describes how you can quickly view the graph using the yEd graph viewer (http://www.yworks.com/en/products_yed_about.htm)

There are some limitations with the current version- singletons created using a static final field and a static initializer are ignored (to avoid false positives with other static usages of final). Inner-class singletons are also missed. A practical limitation is the inability to evaluate either a jar or classes in a directory. Multiple jars must be unpacked in this version.

I tried it out on the hibernate jar (hibernate3.jar):

  1. download gsd-0.7.3 which basically is the gsd.jar
  2. run using a java5 jvm: java -jar gsd.jar hibernate3.jar hibernate3.graphml
  3. download yEd from www.yworks.com- there are several install options, including just a jar file.
  4. run yEd, open hibernate3.graphml. This default layout was a mess of stacked lines and boxes…
  5. re-size text to nodes (Tools-> Fit Node to Label, use default properties)
  6. choose better layout (Layout -> Organic -> Smart, use default properties)

Below is a portion of the graph. Quite a lot of yellow and green boxes, which are identified as ‘mingletons’ and ‘fingletons’ respectively. The blue ovals are classes dependent on -ingletons. Such a graph on your codebase is helpful in visualizing the organization and use of Fingletons, at least as a maintenance exercise.
graph.jpg