This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: FYI: Patch: java.text.SimpleDateFormat merge from classpath
- From: Guilhem Lavaux <guilhem at kaffe dot org>
- To: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- Cc: Michael Koch <konqueror at gmx dot de>, java-patches at gcc dot gnu dot org
- Date: Sat, 27 Sep 2003 16:01:13 +0200
- Subject: Re: FYI: Patch: java.text.SimpleDateFormat merge from classpath
- References: <959EABD8-EFD3-11D7-B9D5-003065F97F7C@mckinlay.net.nz>
Bryce McKinlay wrote:
>
> On Friday, Sep 26, 2003, at 05:27 Pacific/Auckland, Michael Koch wrote:
>
>> I commited the attached patch to trunk to merge
>> java.text.SimpleDateFormat with classpath again.
>
>
>> +2003-09-25 Guilhem Lavaux <guilhem@kaffe.org>
>> +
>> + * java/text/SimpleDateFormat.java (parse): Don't use class calendar
>> + field.
>
>
> This patch doesn't look right. We don't want to be cloning the
calendar object on every parse() call - its a big performance penalty.
If calendar.clear() is not correctly reseting the calendar instance,
then the bug is in Calendar, not SimpleDateFormat.
>
> Guilhem, could you explain the motivation behind this change?
>
> Regards
>
> Bryce
>
Hmm... apparently I should only have done a "new Calendar". I am
clearing it just after.
The problem was that if you try to parse a string using SimpleDateFormat
and you don't create an isolated calendar object you may contamine the
old one. But the old calendar may be used to format new strings and the
mauve tests was doing precisely that. The results were obviously
different as parse used to modify calendar. But I admit I should have
only done a "new GregorianCalendar".
Cheers,
Guilhem.