On Tue, Dec 7, 2010 at 3:25 PM, Dr Andrew John Hughes
<ahug...@redhat.com> wrote:
>> I meant applications relying on the current behavior of OpenJDK so
>> it's probably not worth it to make the behavior "correct" in either of
>> the projects. But sure, I do think your patch is an improvement as-is
>> so I'm for merging your patch even with the stop position calculation
>> (that I think needs to go at some point).
>>
>> Is there some GNU Classpath maintainer around who agrees or disagrees
>> with the patch? What can we do to make the patch more palatable for
>> merging?
>
> I haven't looked at the patch yet. This thread is rather hard to
> follow and doesn't seem to connect to the original patch post.
>
> However, I think the OpenJDK behaviour is correct and the expected
> result of the test case wrong. The NumberFormat class is designed
> for both formatting and parsing. The documentation is rather unclear,
> but does state:
>
> 'NumberFormat and DecimalFormat are designed such that some controls work for
> formatting and others work for parsing'
>
> and
>
> 'You can also control the display of numbers with such methods as
> setMinimumFractionDigits.'
>
> (note the word 'display')
>
> so I believe these setMin, setMax, etc. methods are only meant to affect the
> display of the numbers.
Yeah, makes sense.
> Indeed, if you change the last line of the test case to:
>
> System.out.println(numberFormat.format(numberFormat.parse("1234567890")));
>
> OpenJDK will print "90" while Classpath prints "34" (because of the earlier
> broken parsing). So
> max/min is interpreted right to left.
>
> Thus, Classpath should be fixed to give the same results as OpenJDK.
>
> One thing Classpath could do is document this much better...
Yup. Agreed.
Pekka
