Google Singleton Detector

Posted by Geoffrey Wiseman on Aug 08, 2007

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Java ,

Artifacts & Tools ,

Code Analysis

Tags

Google

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.

1. Back to top

   Thank you!

   by Aslak Hellesøy

   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.

   Reply

2. Back to top

   Using Guice for a better singleton model

   by Rob Di Marco

   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.

   Reply

3. Back to top

   Re: Using Guice for a better singleton model

   by info quack

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

   Reply

4. Back to top

   Isn't this debate primarily a server side debate?

   by Jim Leonardo

   ...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).

   Reply

5. Back to top

   Re: Isn't this debate primarily a server side debate?

   by Alexandre Poitras

   The only valid Singleton (jvm or thread scoped) use case I see is when a context object can be needed by almost all methods of an application. Passing those objects as parameters everywhere just in case is just not pratical and very cumbersome so a singleton is a good solution in those cases in my opinion. A registry (Spring has a registry offers some singleton bootstrap classes) or the current user credentials are some good examples of this situation. Other than that I think that Singletons objects should be avoided and are an anti-pattern.

   Reply

6. Back to top

   Re: Isn't this debate primarily a server side debate?

   by Alexandre Poitras

   The only valid Singleton (jvm or thread scoped) use case I see is when a context object can be needed by almost all methods of an application. Passing those objects as parameters everywhere just in case is just not pratical and very cumbersome so a singleton is a good solution in those cases in my opinion. A registry (Spring has a registry offers some singleton bootstrap classes) or the current user credentials are some good examples of this situation. Other than that I think that Singletons objects should be avoided and are an anti-pattern.

   
   
   Just wanted to add that with a good DI container able to inject dependances in any objects (including objects instancied directly throught the new keyword as Spring 2) there is almost no need anymore for Singletons except bootstrapping the container itself in some cases.

   Reply

7. Back to top

   You're Welcome

   by David Rubel

   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 (davidrubel.blogspot.com/) 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?

   Reply

• Older >