What does new BigDecimal(1.035).toString() print? I suspect your issue is
related to the fact that 1.035 is not, in fact, the value represented as a
double; new DecimalFormat("0.00").format(1.035) formats the closest value
representable as a double to the exact value 1.035.
Louis Wasserman
wasserman.lo...@gmail.com
http://profiles.google.com/wasserman.louis
On Sun, May 4, 2014 at 9:56 AM, <solo-java-core-l...@goeswhere.com> wrote:
> Hey,
>
> Could someone please help me understand what changes have happened in
> rounding in DecimalFormat in Java 8?
>
> new DecimalFormat("0.00").format(1.035) is 1.04 on Java 7, and 1.03 on
> Java 8. (7u25-2.3.10-1~deb7u1, openjdk build 1.8.0_05-b13 debian and
> Oracle build 1.8.0-b132 win64 tested).
>
> My understanding of the RoundingMode.HALF_EVEN (the default)
> documentation is that 1.04 is the correct answer. In fact,
> (0.000, 1.0035) is 1.004, and (0.0, 1.35) is 1.4. I am aware
> that floating point is more complex than this, and I am by no
> means an expert.
>
>
> It seems that this may be new code, with a known breaking change in it:
>
> http://openjdk.java.net/jeps/177:
> > Compatibility: On JDK 7, (correct) but altered numerical behavior will
> > only be enabled under an aggressive optimization flag to limit
> > behavioral compatibility impact in that release train. In Java SE 8,
> > the correct numerical behavior will always be required by the
> > specification.
>
> Did this materialise somewhere, and, if so, where's it documented?
>
>
> In summary: My tests fail on Java 8 and I'm not sure they're wrong.
> Any help would be appreciated, thanks.
>
>
