Conversion Error in JCO due to BigDecimal.toString() change in Java 1.5

Question

Hi folks,
we have a problem here. A field which is set through a java.math.BigDecimal(0) gets very funny values in JCo. We had a look insight JCo und found, that JCo.Record does the following with BigDecimals:
if ((value instanceof BigDecimal) && itype == 2)
   try
     BigDecimal bd=(BigDecimal) value;
     bd=bd.setScale(super.decimals[index], 6);
     encodeBCD(bd.toString(), index);
   catch (Exception ex)
     throw new ConversionException(ex.getMessage());
A value of 0 (and super.decimals[index]==7) is than translatet not to "0.0000000" but to "0E-7". This is a big difference to what JDK 1.4 used to print and encodeBCD fails with "0E-7". JCo with JDK 1.5 should use "toPlainString()" now at this place (or adopt encodeBDC), but that would not be downward compatible anymore...
OK, we solved this issu for now by transforming to a string ourself at a central point befor using "setValue" in JCo. The other way would be to use XML for all settings. But that would mean a change of the whole software.
Does anybody of you know of a different solution we could use? Or will there be a new JCo Version solving this?
Thanks
PS: try this code. It will make all clear to you:
BigDecimal bd = new BigDecimal(0);
BigDecimal bd1 = bd.setScale(7, BigDecimal.ROUND_HALF_EVEN);
BigDecimal bd2 = bd.setScale(6, BigDecimal.ROUND_HALF_EVEN);
System.out.println(bd.toString()+"=="+bd.toPlainString());
System.out.println(bd1.toString()+"!="+bd1.toPlainString());
System.out.println(bd2.toString()+"=="+bd2.toPlainString());
Result is:
0==0
0E-7!=0.0000000
0.000000==0.000000
Message was edited by: Daniel Becker

Answer 1

user712747 wrote:
When we are converting string to BigDecimal, in JAVA 1.5 it is post fixing with extra “0”(zero) if the string value ends with single “ ”0” (zero).That sounds very odd.
To overcome this we can use toPlainString() method in Java 1.5. But it is not feasible to make this change all over places in our code.Aha! This sounds like conversion from BigDecimal to String; not what you described above. And I have to admit, that change mystified me too, because it goes against the grain of backwards-compatibility. It's possible that it was meant to "standardize" output for floating-point values though.
Is there any fix available?Well, one thing might be to use toPlainString() in the places where you're having problems. The string produced by toString() is still suitable for converting back to BigIntegers (and will do so precisely; I believe the toPlainString() style could produce a BigDecimal with the same value but different scale), so unless you actually need the string for viewing you can leave it alone.
But as EJP says, post some code.
Winston