Emmanuel Bourg schrieb:
sebb a écrit :
The static DateFormat is not private, so the synchronization is not
guaranteed.
I'll make it private. I added a comment mentioning that it must be
synchronized.
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.
I left the instance DateFormat package private only to access it from
the test cases. I'll synchronize its use as well.
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.
Indeed, it's a newly created experimental branch.
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.
On the 1.x branch we were parsing a timezone with a SimpleDateFormat,
since this was not supported by Java 1.3 Oliver implemented an
alternative date parser. FastDateFormat could probably replace this
implementation since it supports the timezone and works on Java 1.3.
On the 2.x branch Java 5 is the minimum requirement, so the Java 1.3
compatibility of FastDateFormat is not a compelling reason to adopt it.
Emmanuel Bourg
According to the Javadocs, FastDateFormat is all about formatting, but
does not support parsing. That's why I wrote a parser myself.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
