Hi, Dan, still tracking this down, but I had to smile -- the first level answer I got back from the J2SE folks was that these changes were made as part of JSR13, which was driven by IBM. Maybe you should find the guys behind JSR13 and give them an earful :)
David Daniel John Debrunner wrote: > I'm wonder if any of the Sun folks on the list can help out, J2SE 5.0 > has changed the behaviour of java.math.BigDecimal in incompatible ways > from JDK 1.4.x, but these are not mentioned in > > http://java.sun.com/j2se/1.5.0/compatibility.html > > Is there any document that details all the ways J2SE 5.0's BigDecimal is > incompatible with all earlier Java releases? > > While we changed Derby to address the change in behaviour of > BigDecimal.toString() a while ago, I just discovered another change that > breaks Derby and potentially other applications. The method > BigDecimal.scale() used to be > > (JDK 1.4.1 javadoc) > Returns the scale of this BigDecimal. (The scale is the number of digits > to the right of the decimal point.) > > but now it can return negative numbers > > (J2SE 5.0 docs) > Returns the scale of this BigDecimal. If zero or positive, the scale is > the number of digits to the right of the decimal point. If negative, the > unscaled value of the number is multiplied by ten to the power of the > negation of the scale. For example, a scale of -3 means the unscaled > value is multiplied by 1000. > > > I discovered this when looking at Derby-225 and simple cleanup changes > that should have not fixed the issue suddenly fixed it. Further > investigation showed a scale of -302 which of course confused the > existing code. > > I wonder if there are any more incompatibilities in this class that > could break Derby code? > > Thanks, > Dan. >
