[lang] FastDateFormat Update

[Sean Schofield]

FastDateFormat has finally been added to CVS. As mentioned in earlier emails, this source code was originally written by Brian O'Neill and reused/modified with his permission. This email contains a summary of the changes made as well as issues to be resolved.

Changes already made:
=====================

1) I removed two of the overloaded getInstance() methods that took DateFormatSymbols as arguments. SimpleDateFormat does allow a DateFormat to be constructed using DateFormatSymbols but I thought for now it might be nice to leave this out. It could be argued, however, that we should include support for this, since some have described this class as a thread-safe replacement for SimpleDateformat. (Actually the changes related to this were commented-out for now so we can undo them if people want.)
2) Removed 'throws IllegalArgumentException' from several methods. IMO, runtime exceptions should not be declared in the method. I checked several other classes in commons-lang and it seems that this follows the current commons-lang coding convention as well.

3) Changed the "style" argument in getDateInstance() and getTimeInstance() from Object to int since the method was converting everything to int anyways. (Forgot to do this for getDateTimeInstance() but this will suffice for now as I'm not even sure we want to keep these methods in this class [see next section].)

4) Changed Brian's Pair.java to be a private static inner class of FastDateFormat.


Proposed/Anticipated Changes
============================

1) Clean up source code (including javadoc) to conform to commons-lang style. So fart this has been done with my changes only in an attempt to get things checked in and get some feedback. The code should be cleaned up as we polish this (and the test class.)

2) Eliminate getDateInstance(), getDateTimeInstance(), and getTimeInstance() from FastDateFormat. I think the goal behind these methods is fine but I don't think they belong in this class which is supposed to be a light-weight and thread-safe SimpleDateFormat replacement. Earlier we had discussed the ability to have some common date/time formats available in DateUtils. This is where I propose this functionality be moved to.

3) If we don't eliminate the methods in proposal #2, then we need to investigate them for thread-saftey. They are all using SimpleDateFormat methods and its been mentioned that some of these methods are not thread safe (not sure if there is a problem with the specific ones used here.)

4) Consider replacing use of HashMap due to the problem that Dick has mentioned.

Any thoughts?

- sean


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>