Just yesterday, at work, I caught more code using java.util.DateFormat in a non-safe way, so today I looked through old mail and the like trying to find one of the better summaries of the DateFormat situation I’d read. I found this one :


I mentions the non thread-safety of the DateFormat class (something that ought to be well known by now!), and lightly discusses ideas for working around the problem.

What’s missing from the post above, however, is any discussion of how developers might find and correct all of their existing DateFormat usage after learning about this problem, and how they might prevent further incorrect usage in the future.

This is where static analysis comes in. PMD, a popular Java-language static analysis tool, already has a rule relating to thread-safe DateFormat usage. This page :


mentions the below rule :

UnsynchronizedStaticDateFormatter: SimpleDateFormat is not synchronized. Sun recommends separate format instances for each thread. If multiple threads must access a static formatter, the formatter must be synchronized either on method or block level.

This rule likely would have caught the above mentioned problem at Atlassian, and certainly would have prevented the similar problem in my company’s code (I checked).

Overall, I’m surprised to see development teams doing very little with static analysis, as there is quite a bit of low-hanging-fruit to be gained from tools such as PMD and FindBugs.


Sometimes a dead-simple feature hides from me for exactly that reason, because the feature is so dead simple.

Such was the case of Eclipse being able to pop out various parts of its view into multiple separate windows, something I just recently learned from this Adrian Coyler posting from well over a year ago, the English original of this article he wrote for the German-language “Eclipse Magazin”.

To pop all or part of an Eclipse view into its own window, just DRAG the view outside of the main window. That’s it. See that ‘Problems’ tab? Drag it to its own window. The ‘Package Explorer’ tab? Another window. At last, my Eclipse can take advantage of my nice multi-monitor setup.

I was asked for Eclipse plugin recommendations last month, by someone who’d just started doing Java development again after quite a bit of time doing .Net development. I wrote down a short list of the common settings, plugins, ans so forth I recommend to the developers I work with.

While writing the list, I realized I can babble about Eclipse setup for far longer than anyone cares to listen, so I’ve pared things down to five initial setup recommendations:

  1. Download an Eclipse milestone. Their usually stable enough for day-to-day use.
  2. Edit the Java compiler settings, turning all the warnings on. Turn off the ones that completely bug you after a few hours.
  3. Set up an extension location to install any plugins into. You’ll be glad you did. Lots of sites discuss this idea; I often point folks here for details.
  4. Install some plugins. I recommend the Web Tools Platform for web developers, PMD for developers who need to review more other’s projects, and the Freemarker plugin for anyone working with Freemarker templates.
  5. Look around on the web any time you wish Eclipse did something it doesn’t. There are plugins and setup options to match all sorts of situation.