You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mike Ringrose <mi...@gmail.com> on 2006/11/04 04:18:34 UTC
Behaving differently than RI
Before submitting a bug to JIRA, I was curious to know, how exact should
Harmony behave when compared to the RI. For example, the code below produces
different results when compared to the RI.
DecimalFormat f = new DecimalFormat(".1");
System.out.println(f.format(17.16));
Harmony outputs 17.2, while the RI outputs 17.1. The reason for the
difference is that Harmony's underlying implementation is taken from ICU
which supports options other than what is specified by the RI.
Should this difference be considered a bug?
Thanks,
Mike Ringrose
Re: Behaving differently than RI
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Mike Ringrose wrote:
> Before submitting a bug to JIRA, I was curious to know, how exact should
> Harmony behave when compared to the RI. For example, the code below
> produces
> different results when compared to the RI.
>
> DecimalFormat f = new DecimalFormat(".1");
> System.out.println(f.format(17.16));
>
> Harmony outputs 17.2, while the RI outputs 17.1. The reason for the
> difference is that Harmony's underlying implementation is taken from ICU
> which supports options other than what is specified by the RI.
>
> Should this difference be considered a bug?
Yes :)
We will differ from the RI rarely, when we've decided that there is
limited risk to breaking users applications, which we feel is important.
IOW, we're going to be compatible with the spec, but also compatible
with the breakage in the RI when necessary.
Thanks - file that JIRA (and for bonus points, include a test case. For
the gold star, include the fix :)
geir
>
> Thanks,
> Mike Ringrose
>
Re: Behaving differently than RI
Posted by Mike Ringrose <mi...@gmail.com>.
ICU would not see this as a bug, because it is a feature of their
implementation of DecimalFormat. The pattern ".1" for ICU means to round the
value to the nearest tenth, while the RI takes it literally. If you look at
the JavaDocs for ICU, you'll see the following message:
*This is an enhanced version of DecimalFormat that is based on the standard
version in the JDK. New or changed functionality is labeled NEW or CHANGED.
[1]
This is why I chose my example, the ICU version is an "enhanced" version of
DecimalFormat that extends the RI implementation. I'm not sure if this
should be deviation from the RI should be considered a bug. However, if it
is, then this issue could be problematic for Harmony using the ICU's
implementation.
[1]
http://icu.sourceforge.net/apiref/icu4j/com/ibm/icu/text/DecimalFormat.html
Mike Ringrose
*On 11/6/06, Spark Shen <sm...@gmail.com> wrote:
>
> Alexey Petrenko 写道:
> > Hi, Mike.
> >
> > You can find compatybility guideline for Harmony here:
> >
> http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
> >
> >
> > According to your testcase. I think it is a bug and you should file it
> > to JIRA.
> AFAIK, ICU has its own mailing list[1]. If that incompatibility is
> considered a bug, delegate to ICU development team may be more efficient.
>
> [1] "ICU support mailing list" <ic...@lists.sourceforge.net>
> >
> > SY, Alexey
> >
> > 2006/11/4, Mike Ringrose <mi...@gmail.com>:
> >> Before submitting a bug to JIRA, I was curious to know, how exact
> should
> >> Harmony behave when compared to the RI. For example, the code below
> >> produces
> >> different results when compared to the RI.
> >>
> >> DecimalFormat f = new DecimalFormat(".1");
> >> System.out.println(f.format(17.16));
> >>
> >> Harmony outputs 17.2, while the RI outputs 17.1. The reason for the
> >> difference is that Harmony's underlying implementation is taken from
> ICU
> >> which supports options other than what is specified by the RI.
> >>
> >> Should this difference be considered a bug?
> >>
> >> Thanks,
> >> Mike Ringrose
> >>
> >>
> >
>
>
> --
> Spark Shen
> China Software Development Lab, IBM
>
>
Re: Behaving differently than RI
Posted by Spark Shen <sm...@gmail.com>.
Alexey Petrenko 写道:
> 2006/11/6, Spark Shen <sm...@gmail.com>:
>> Alexey Petrenko 写道:
>> > Hi, Mike.
>> >
>> > You can find compatybility guideline for Harmony here:
>> >
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
>>
>> >
>> >
>> > According to your testcase. I think it is a bug and you should file it
>> > to JIRA.
>> AFAIK, ICU has its own mailing list[1]. If that incompatibility is
>> considered a bug, delegate to ICU development team may be more
>> efficient.
> Right.
> But even if it is an ICU bug I think that it will be good to have also
> Harmony JIRA entry with the link to corresponding ICU issue.
Agree with you to report a JIRA to record this issue.
>
> SY, Alexey
>
>> [1] "ICU support mailing list" <ic...@lists.sourceforge.net>
>
>> > 2006/11/4, Mike Ringrose <mi...@gmail.com>:
>> >> Before submitting a bug to JIRA, I was curious to know, how exact
>> should
>> >> Harmony behave when compared to the RI. For example, the code below
>> >> produces
>> >> different results when compared to the RI.
>> >>
>> >> DecimalFormat f = new DecimalFormat(".1");
>> >> System.out.println(f.format(17.16));
>> >>
>> >> Harmony outputs 17.2, while the RI outputs 17.1. The reason for the
>> >> difference is that Harmony's underlying implementation is taken
>> from ICU
>> >> which supports options other than what is specified by the RI.
>> >>
>> >> Should this difference be considered a bug?
>> >>
>> >> Thanks,
>> >> Mike Ringrose
>> >>
>> >>
>> >
>>
>>
>> --
>> Spark Shen
>> China Software Development Lab, IBM
>>
>>
--
Spark Shen
China Software Development Lab, IBM
Re: Behaving differently than RI
Posted by Alexey Petrenko <al...@gmail.com>.
2006/11/6, Spark Shen <sm...@gmail.com>:
> Alexey Petrenko 写道:
> > Hi, Mike.
> >
> > You can find compatybility guideline for Harmony here:
> > http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
> >
> >
> > According to your testcase. I think it is a bug and you should file it
> > to JIRA.
> AFAIK, ICU has its own mailing list[1]. If that incompatibility is
> considered a bug, delegate to ICU development team may be more efficient.
Right.
But even if it is an ICU bug I think that it will be good to have also
Harmony JIRA entry with the link to corresponding ICU issue.
SY, Alexey
> [1] "ICU support mailing list" <ic...@lists.sourceforge.net>
> > 2006/11/4, Mike Ringrose <mi...@gmail.com>:
> >> Before submitting a bug to JIRA, I was curious to know, how exact should
> >> Harmony behave when compared to the RI. For example, the code below
> >> produces
> >> different results when compared to the RI.
> >>
> >> DecimalFormat f = new DecimalFormat(".1");
> >> System.out.println(f.format(17.16));
> >>
> >> Harmony outputs 17.2, while the RI outputs 17.1. The reason for the
> >> difference is that Harmony's underlying implementation is taken from ICU
> >> which supports options other than what is specified by the RI.
> >>
> >> Should this difference be considered a bug?
> >>
> >> Thanks,
> >> Mike Ringrose
> >>
> >>
> >
>
>
> --
> Spark Shen
> China Software Development Lab, IBM
>
>
Re: Behaving differently than RI
Posted by Spark Shen <sm...@gmail.com>.
Alexey Petrenko 写道:
> Hi, Mike.
>
> You can find compatybility guideline for Harmony here:
> http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
>
>
> According to your testcase. I think it is a bug and you should file it
> to JIRA.
AFAIK, ICU has its own mailing list[1]. If that incompatibility is
considered a bug, delegate to ICU development team may be more efficient.
[1] "ICU support mailing list" <ic...@lists.sourceforge.net>
>
> SY, Alexey
>
> 2006/11/4, Mike Ringrose <mi...@gmail.com>:
>> Before submitting a bug to JIRA, I was curious to know, how exact should
>> Harmony behave when compared to the RI. For example, the code below
>> produces
>> different results when compared to the RI.
>>
>> DecimalFormat f = new DecimalFormat(".1");
>> System.out.println(f.format(17.16));
>>
>> Harmony outputs 17.2, while the RI outputs 17.1. The reason for the
>> difference is that Harmony's underlying implementation is taken from ICU
>> which supports options other than what is specified by the RI.
>>
>> Should this difference be considered a bug?
>>
>> Thanks,
>> Mike Ringrose
>>
>>
>
--
Spark Shen
China Software Development Lab, IBM
Re: Behaving differently than RI
Posted by Alexey Petrenko <al...@gmail.com>.
Hi, Mike.
You can find compatybility guideline for Harmony here:
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
According to your testcase. I think it is a bug and you should file it to JIRA.
SY, Alexey
2006/11/4, Mike Ringrose <mi...@gmail.com>:
> Before submitting a bug to JIRA, I was curious to know, how exact should
> Harmony behave when compared to the RI. For example, the code below produces
> different results when compared to the RI.
>
> DecimalFormat f = new DecimalFormat(".1");
> System.out.println(f.format(17.16));
>
> Harmony outputs 17.2, while the RI outputs 17.1. The reason for the
> difference is that Harmony's underlying implementation is taken from ICU
> which supports options other than what is specified by the RI.
>
> Should this difference be considered a bug?
>
> Thanks,
> Mike Ringrose
>
>