This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Java in General and the fly likes java.text.Format is not thread-safe Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "java.text.Format is not thread-safe" Watch "java.text.Format is not thread-safe" New topic
Author

java.text.Format is not thread-safe

Mike Thomson
Ranch Hand

Joined: Nov 07, 2007
Posts: 115
Below one is extracted from
http://www.fortify.com/vulncat/en/vulncat/java/race_condition_format_flaw.html

ABSTRACT
The methods parse() and format() in java.text.Format contain a design flaw that can cause one user to see another user's data.


EXPLANATION
The methods parse() and format() in java.text.Format contains a race condition that can cause one user to see another user's data.

Example 1: The code below shows how this design flaw can manifest itself.




While this code will behave correctly in a single-user environment, if two threads run it at the same time they could produce the following output:

Time in thread 1 should be 12/31/69 4:00 PM, found: 12/31/69 4:00 PM
Time in thread 2 should be around 12/29/09 6:26 AM, found: 12/29/09 6:30 AM

In this case, the date from the first thread is shown in the output from the second thread due a race condition in the implementation of format().



So format() is not threadsafe. I am using format() in many places in servlet. Instead of synchroized the methos or using synch block, can I make the variable local so that it will thread safe. Please advice that approach will address the above issue.

Instead of gloabl var (private static SimpleDateFormat dateFormat;), making dateFormat as local var will solve the issue for above case
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41127
    
  45
Yes, making the object local will avoid thread safety issues.

This is not a design flaw, though, it's a design decision - the javadocs specifically mention that the class is not thread-safe (as they do for many other classes). So it's clear that the developer needs to provide that.


Ping & DNS - my free Android networking tools app
Mike Thomson
Ranch Hand

Joined: Nov 07, 2007
Posts: 115
Thanks a lot for the confirmation.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19654
    
  18

This was also discussed here. Check out my ThreadLocal object in there.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

The reason why it's not thread-safe is because synchronization has runtime overhead (it makes the program run a little bit slower) and most of the time you don't need thread safety with for example a SimpleDateFormat object, because you're most of the time not using the same SimpleDateFormat object from multiple threads at the same time.

One way to avoid thread safety issues is by making the SimpleDateFormat a local variable; another way is by using thread-local storage. When you do this, a separate SimpleDateFormat object will be created for every thread that uses it. You do that like this:

So you wrap the DateFormat object in a ThreadLocal. Note that you have to call get() on the ThreadLocal (see line 14) to get the actual DateFormat object.

*edit* too late...

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: java.text.Format is not thread-safe
 
Similar Threads
Bug in SimpleDateFormat? Is that you also experienced?
String GMT Date conversion to EST/EDT
TimeZone Conversion
date
Date Formate Problem