Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Google Singleton Detector

Google Singleton Detector

This item in japanese


Google has released a tool that performs bytecode analysis in order to locate and report on Singletons within bytecode. Although Singletons are a common software pattern, many people consider them controversial, to be used carefully: arguments can be made both for and against. As stated in the project wiki:

The problem with singletons is that they introduce global state into a program, allowing anyone to access them at anytime (ignoring scope). Even worse, singletons are one of the most overused design patterns today, meaning that many people introduce this possibly detrimental global state in instances where it isn't even necessary.
[P]rograms using global state are very difficult to test ... When one class uses a singleton (and I'm talking about a classic singleton, one that enforces it own singularity thorough a static getInstance() method), the singleton user and the singleton become inextricably coupled together.
[R]elying on this static instance means that the signatures of methods no longer show their dependencies, because the method could pull a singleton “out of thin air.” This means that users need knowledge of the inner workings of code to properly use it, making it more difficult to use and test.
Because the dependencies of some given methods aren't clear when they rely on singletons, a tester may unknowing write two tests that actually depend on each other by modifying a shared resource.

The Google Singleton Detector can detect code that enforces its own singularity (singleton), helps enforce the singularity of another class (helper singleton, or 'hingleton'), returns state from a static methods without taking parameters (method singleton, or 'mingleton'), has a public static field (field singleton, or 'fingleton'), as well as code that directly relies on one of the above. You may hide some of these if you're not interested.

This is still a tool in a relatively early stage, and there are a few limitations:

  • It cannot read bytecode from multiple JARs without extracting them first.
  • It requires an external tool to view graph results.
  • It can't find all kinds of singletons, specifically not those in final fields or nested as an inner class.

Stay tuned to InfoQ for more information about code analysis, artifacts and tools and Google.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Thank you!

    by Aslak Hellesøy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is actually a tool I have been wanting to write for years! Finally a way to fail the build when the crap accidentally enters the codebase ;-) Looking forward to trying it out.

  • Using Guice for a better singleton model

    by Rob Di Marco,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One question you may think when reading this article is "Is there a better pattern/library to use in my Java applications instead of singletons?" I would recommend that you check out Guice, also from Google. It is a nifty tool that will replace singleton and factories in your code and in my experience, is really helpful when trying to insert mock instances during unit testing.

  • Re: Using Guice for a better singleton model

    by info quack,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Alternatively, right click on source and search for 'static getInstance()' ??

  • Isn't this debate primarily a server side debate?

    by Jim Leonardo,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    ...There being far more valid reasons to use singleton in a client side app than a server side app. It would be nice if the article distinguished the two. Still, like any pattern, it should be used judiciously, not capriciously. Poor use/Overuse of Singleton can cause problems for multi-threaded apps among other issues.

    And...Believe it or not, people do occasionally write those thick client apps still.

    That said, I'm interested in seeing how it handles the difference between a singleton and other "static" based construction techniques/patterns. Banning the appearance of static from your code seems a little too fanatical to me (which the guice page seems to imply would be a good thing).

  • You're Welcome

    by David Rubel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hey, this is actually my project over at Google, and I just wanted to say a few things...

    We actually can read bytecode form multiple jars now (it was a pain to extract some of the larger projects).

    If you'd like to get an idea of the output GSD produces, check out my blog ( for graphs of some common open source projects.

    Also, we've been looking for a project in the open source community that used to be riddle with singletons and is now reliant on DI. Any suggestions?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p