On 15/02/2008, Emmanuel Bourg <[EMAIL PROTECTED]> wrote: > sebb a écrit : > > > > BTW, SimpleDateFormat is not synchronized, so having package-protected > > instances (whether static or not) may cause problems if the class is > > intended for multithreaded use. > > > I made so the usage of the static DateFormat is synchronized. The > instance DateFormat isn't synchronized but its use by concurrent threads > is unlikely. I can change it though if it's really an issue. >
The static DateFormat is not private, so the synchronization is not guaranteed. Likewise the instance DateFormat. Indeed that is worse, since the format is temporarily changed by the private method - even if the field is made private, the method(s) that use it are potentially thread-hostile. Seems to me that the DateFormats should both be private. Also, unless the access is synchronized, any public methods that use the instance format should be documented as not being thread safe (in fact thread-hostile). > > > Also, the serialVersionUID should probably be changed as a new > > instance field has been added. > > > The package name has changed, is it still necessary to change the UID ? > As far as I can tell the package name was not changed in this update, but if the previous version of the class was never deployed then it's probably not necessary. > > > Perhaps consider using org.apache.commons.lang.time.FastDateFormat > > from Commons Lang for at least the formatting part? > > > FastDateFormat could be useful to simplify the code on the 1.x branch, > but for the 2.x code base I think SimpleDateFormat is good enough. I don't follow that reasoning. > Emmanuel Bourg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
