----- Original Message ----- From: "Henri Yandell" <[EMAIL PROTECTED]> > On Tue, 7 Jan 2003, Sean Schofield wrote: > > 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.) > > If there's no reason as to why they're a pain to keep in, would be nice to > not get some javadoc-lawyer hitting us with the reason why FastDateFormat > isn't a SimpleDateFormat replacement.
Its not a SimpleDateFormat drop-in as it doesn't extend Format. It should do (not the parsing, just the formatting part - throw UnsupportedOperationException from the parsing) > > 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. > > I think this is quite debatable and up-in-the-air. You're not shattering > any rules by not having them in there, but there's a definite school of > thought in favour of them being there. I oppose putting runtime exceptions in the throws clause, and so support their removal. Probably should change developers-guide. > > 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].) > > Again, depends on how much we care about being a drop-in replacement. > > > Proposed/Anticipated Changes > > ============================ > > > > 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. > > Assuming we don't advertise as a drop-in replacement, I like the DateUtils > idea. As usual, I'm easily swayed by the opinion of the coder closest :) > Dunno about others. I don't see any great advantage to separating the factory from the class (they don't separate them in JDK). I propose the style would be FULL, LONG, MEDIUM, SHORT, ISO, ISO_FULL. They should be defined using the Enum subpackage. (ISO_FULL includes milliseconds) Also, there should only be one constructor, and it should be protected in case someone else wants to subclass. > > 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.) > > Ah. Good enough reason to eliminate them. Just got to avoid the drop-in > catchphrase. I've taken a look and the calls should be threadsafe. They just get the pattern. Its the actual formatting thats not threadsafe. Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
