BT

Google Singleton Detector

| by Geoffrey Wiseman Follow 0 Followers on Aug 08, 2007. Estimated reading time: 1 minute |

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

Adoption Stage
Style

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.

Tell us what you think

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

Email me replies to any of my messages in this thread

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.

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.

Re: Using Guice for a better singleton model by info quack

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

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

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.

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.

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?

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

7 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT