DateFormats are not thread-safe, meaning that they maintain an internal representation of state. Using them in a static context can yield some pretty strange bugs if multiple threads access the same instance simultaneously.
My suggestion would be to make your variables local to where you're using them instead of making them static properties of the class. It looks like you might be doing this when you're initializing the class, so you could do this in the constructor:
public class MyClass {
private String fileName;
public MyClass() {
final Date today = Calendar.getInstance().getTime();
final DateFormat yymmdd = new SimpleDateFormat("yyMMdd");
this.fileName = "file_" + yymmdd.format(TODAY);
}
...
}
And if you need to use the formatter in multiple places, you might just make the pattern static final
and create a new local DateFormat
when needed:
public class MyClass {
private static final String FILENAME_DATE_PATTERN = "yyMMdd";
public void myMethod() {
final DateFormat format = new SimpleDateFormat(FILENAME_DATE_PATTERN);
// do some formatting
}
}
The FindBugs documentation for the issue says:
As the JavaDoc states, DateFormats are
inherently unsafe for multithreaded
use. The detector has found a call to
an instance of DateFormat that has
been obtained via a static field. This
looks suspicous.
For more information on this see Sun
Bug #6231579 and Sun Bug #6178997.
And the javadoc for DateFormat suggests:
Date formats are not synchronized. It
is recommended to create separate
format instances for each thread. If
multiple threads access a format
concurrently, it must be synchronized
externally.
Jack Leow's answer also has a good point about the semantics of your static use of "TODAY".
As an aside, I've actually seen this happen in a high-traffic production environment, and it's a very confusing thing to debug at first; so in my experience the FindBugs warning is actually a useful suggestion (unlike some other static analysis rules, which sometimes seem to be nitpicky).