On 00:19 Tue 07 Dec , Pekka Enberg wrote:
> 2010/12/6 Ivan Maidanski <iv...@mail.ru>:
> >> Googling around doesn't seem to bring anything on the topic which
> >> makes me think this is an old bug that nobody really cares about but
> >> there can be applications out there that rely on the current behavior
> >> that would be broken under GNU Classpath.
> >
> > Not would - is broken now. The patch would make it "less" broken.
> > (returning 4 digits for the test case is definitely wrong here) Why not to
> > fix this first (a long with the other bugs fixed by the proposed patch) and
> > then think (discuss with the community) should we remove "stop" position
> > calculation or not (if yes then prepare a separate small patch for it).
>
> 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.
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...
> Pekka
>
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
