Re: [lang] FastDateFormat Update

Any reason why we can't just delegate the parse() method to the SimpleDateFormat? Wouldn't there be some thread-safety issues there? If not, then this is a possibility. If we don't extend Format, I think it should be called FastDateFormatter. How about we call it FastDateFormatter? Th

Re: [lang] FastDateFormat Update

On Wed, 8 Jan 2003, Sean Schofield wrote: > >Yup. Definitely _has_ to extend Format. Even if it isn't seen as a > >SimpleDateFormat option. > > > So are you saying it should extend Format? Why should this be required? > And if we do want to extend Format, what do you we do about the parsing >

Re: [lang] FastDateFormat Update

On Tue, 7 Jan 2003, Stephen Colebourne wrote: - 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 a

Re: [lang] FastDateFormat Update

On Tue, 7 Jan 2003, Stephen Colebourne wrote: > - 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

Re: [lang] FastDateFormat Update

From: "Henri Yandell" <[EMAIL PROTECTED]> > Any particular reason not to use a synchronised Map? > > I guess it's the trade-off between the speed of a Hashtable and the > nicer-API of a Map. Hashtable implements Map ;-) Stephen -- To unsubscribe, e-mail: For addit

Re: [lang] FastDateFormat Update

- 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 DateFor

Re: [lang] FastDateFormat Update

On Tue, 7 Jan 2003, Sean Schofield wrote: > Thanks for the feedback. FastDateFormat doesn't seem to be as thread > safe as advertised (at least in the version we are using.) There are a > few instances of HashMap (some of which I was already proposing to > eliminate b/c they are only being use

Re: [lang] FastDateFormat Update

Thanks for the feedback. FastDateFormat doesn't seem to be as thread safe as advertised (at least in the version we are using.) There are a few instances of HashMap (some of which I was already proposing to eliminate b/c they are only being used by the getDateTimeInstance, etc. methods). I

Re: [lang] FastDateFormat Update

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 f

[lang] FastDateFormat Update

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: ===