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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > SY, Alexey > > 2006/11/4, Mike Ringrose <[EMAIL PROTECTED]>: >> 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
