Hi Pekka and Andrew,
I've attached the patch classpath-ivmai-41.diff.txt (a simple one) that sets
stop pos to the end of line (as in the RI). This patch assumes
classpath-ivmai-39.diff applied.
Changelog entries:
* java/text/DecimalFormat.java: (parse): Set parse stop position to
the end of string (to match the RI behavior); create number string
buffer specifying its capacity.
Regards.
Tue, 7 Dec 2010 15:30:37 +0200 Pekka Enberg <penb...@kernel.org>:
> 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
diff -ru CVS/classpath/java/text/DecimalFormat.java
updated/classpath/java/text/DecimalFormat.java
--- CVS/classpath/java/text/DecimalFormat.java 2010-12-07 23:27:03.512436500
+0300
+++ updated/classpath/java/text/DecimalFormat.java 2010-12-11
20:55:54.946094000 +0300
@@ -659,26 +659,16 @@
char decimalSeparator = symbols.getDecimalSeparator();
char zero = symbols.getZeroDigit();
char exponent = symbols.getExponential();
-
- // stop parsing position in the string
- int stop = start + maximumIntegerDigits;
- if (maximumFractionDigits > 0)
- stop += maximumFractionDigits + 1;
- if (useExponentialNotation)
- stop += (minExponentDigits > 0 ? minExponentDigits : 1) + 2;
+ char groupingSeparator = symbols.getGroupingSeparator();
boolean inExponent = false;
- // correct the size of the end parsing flag
- int len = str.length();
- if (len < stop) stop = len;
- char groupingSeparator = symbols.getGroupingSeparator();
-
// this will be our final number
- CPStringBuilder number = new CPStringBuilder();
+ int len = str.length();
+ CPStringBuilder number = new CPStringBuilder(len - start);
int i;
- for (i = start; i < stop; i++)
+ for (i = start; i < len; i++)
{
char ch = str.charAt(i);
if (ch >= zero && ch <= (zero + 9))
