On Tue, 7 Jan 2003, Sean Schofield wrote:
> 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.) 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. > 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. Lang needs to standardise its approach here. > 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. > 4) Changed Brian's Pair.java to be a private static inner class of > FastDateFormat. +1. Good move. > 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.) Fart's a good word here. Don't worry if you have to ask about a style-point and it launches an argument. As long as we add decisions to the developer's guide, each point is worth it. > 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. > 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. > 4) Consider replacing use of HashMap due to the problem that Dick has > mentioned. Damn. Now you make me have to pay attention to 2 emails at once. No clue which one was this though. If it was synchronisation, Collections.synchronizedMap(new HashMap()) ? Hen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
