Issue Details (XML | Word | Printable)

Key: LANG-367
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Sebb
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Commons Lang

FastDateFormat thread safety

Created: 30/Oct/07 01:25 PM   Updated: 24/Apr/08 01:35 PM
Return to search
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Licensed for inclusion in ASF works FastDateFormat.patch 2007-10-30 01:25 PM Sebb 1 kB
Issue Links:
Duplicate
 

Resolution Date: 05/Nov/07 09:55 AM


 Description  « Hide
FastDateFormat has several static HashMaps. These are currently not final, so there is no guarantee that they will be visible to all threads.

Patch to follow.

Also, as far as I can make out, the class shares SimpleDateFormat instances between threads.

It does not document why this is OK.

I'm guessing that it assumes that instances of the SimpleDateFormat class are thread-safe provided that they have the same attributes, but this is not documented. If this is the case, it's not clear that it is a valid assumption.



 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sebb added a comment - 30/Oct/07 01:25 PM
Make HashMaps final

Henri Yandell added a comment - 31/Oct/07 04:04 AM
Patch applied (r590552).

Keeping open until the SimpleDateFormat question is answered.


Paul Benedict added a comment - 31/Oct/07 04:38 AM
Based on this link:
http://www.ibm.com/developerworks/java/library/j-jtp09263.html

"In any case, it's better to be clear in the documentation about how a class behaves when an instance is shared across threads. As an example of this pitfall, the class java.text.SimpleDateFormat is not thread-safe, but it wasn't until the 1.4 JDK that this was documented in the Javadoc. How many developers mistakenly created a static instance of SimpleDateFormat and used it from multiple threads, unaware that their programs were not going to behave correctly under heavy load? Don't do this to your customers or colleagues!"


Henri Yandell added a comment - 03/Nov/07 07:18 AM
I don't think the SimpleDateFormat sharing is a problem. While it's shared between threads, only one method touches each instance of SimpleDateFormat (there are three separate pools), and each of those methods are synchronized.

Sebb added a comment - 03/Nov/07 04:04 PM
The getInstance() methods are synchronised, but the format() methods are not.

As far as I can tell, the instances that are obtained from getInstance() may be shared between threads, and the format() methods are those of the SimpleDateFormat class.

It may be true that the SimpleDateFormat format() methods are thread-safe under the conditions of this class.

However this assumption is neither documented nor justified.


Henri Yandell added a comment - 03/Nov/07 09:30 PM
The format methods don't hit SimpleDateFormat though - they're the ones getting replaced.

Sebb added a comment - 05/Nov/07 09:55 AM
Sorry, was misreading the usage of SimpleDataFormat.

The class is only instantiated to obtain its pattern as a String - so there is no sharing of SDF instances.

The remarks about sharing SDF instances are wrong.