|
From: Keats K. <ke...@xa...> - 2006-03-30 15:05:37
|
Good catch Endre! Glad I didn't go down that path yet. Perhaps we should look for an alternative date formatting system. I found something called Joda Time on SourceForge (http://www.joda.org/) that looks like it might fit the bill. From their FAQ: "The most common multi-threading mistake made by Java programmers is in the use of SimpleDateFormat. Calling its format method on a shared instance by concurrent threads can produce bizarre results. All of Joda-Time's formatting classes are thread-safe and immutable." They also claim it is faster than SimpleDateFormat. Keats Endre Stølsvik wrote: >... > >| Is (Simple)DateFormat itself completely thread-safe, by contract? > >Forgot to point out that you obvioulsy may just do both the map-lookup >_and_ the formatting within the one synch-block (but then you can forget >the benefit of ConcurrentHashMap) - or you could have a pool of each >format - say 10 instances - and actually do "connection pooling" logic. > But at that point, I do hope that more than me thinks that having "one >more cached resource" (with the synch and potential contention hit (now >both for the synch and the formatting-time), and "memory bloat") for that >amazingly little benefit (e.g. 1 ms for 40 formattings) isn't worth the >hassle? > >Add a method to dateTool that actually gives you a DateFormat back, and >javadoc both methods where the users are told to use the >DateFormat-returning one if they're about to format multiple dates in one >rendering. > >Regards, >Endre. > > |