: - initialValue doesn't need to be synchronized... it's just that way in
: the javadoc example because they were incrementing a global counter
Ah, good eye.
: - the trick you are trying in the ThreadLocalDateFormat aren't
: necessary. no method will be called until the constructor has
: completed. the java memory model also ensures that you see a completely
: constructed object from another thread, even if you haven't
: synchronized. The extra variable won't hurt either... the JVM will
: completely optimize it away (so this is just an FYI).
I think you are giving me more credit then i deserve ... what trick do you
think i'm trying to accomplish?
You're talking about the local "tmp" formatter and which is then assigned
to "proto" at the end? ... that wasn't out of any fear that it would be
used before i set the timezeon, it was just because my inate distaste for
declaring member variables with concrete types wouldn't let write
"SimpleDateFormat proto;" ... so i could either use a tmp var, or cast it
to call setTimeZone -- and if there is one thing i loath more then member
vars with concrete types, it's casting (I was very bitter to discover that
Clonable isn't a parametric type in java5 ... i relly wanted to write...
private static class ThreadLocalDateFormat extends ThreadLocal<DateFormat> {
Clonable<DateFormat> proto;
public ThreadLocalDateFormat() {
...
}
protected synchronized DateFormat initialValue() {
return proto.clone();
}
}
-Hoss
