views:

422

answers:

2

Hello,

I've recently migrated a Java 1.4 application to a Java 6 environment. Unfortunately, I encountered a problem with the BigDecimal storage in a Oracle database. To summarize, when I try to store a "7.65E+7" BigDecimal value (76,500,000.00) in the database, Oracle stores in reality the value of 7,650,000.00. This defect is due to the rewritting of the BigDecimal class in Java 1.5 (see here).

In my code, the BigDecimal was created from a double using this kind of code:

BigDecimal myBD = new BigDecimal("" + someDoubleValue);
someObject.setAmount(myBD);
// Now let Hibernate persists my object in DB...

In more than 99% of the cases, everything works fine. Except that in really few case, the bug mentioned above occurs. And that's quite annoying.

If I change the previous code to avoid the use of the String constructor of BigDecimal, then I do not encounter the bug in my uses cases:

BigDecimal myBD = new BigDecimal(someDoubleValue);
someObject.setAmount(myBD);
// Now let Hibernate persists my object in DB...

However, how can I be sure that this solution is the correct way to handle the use of BigDecimal?

So my question is to know how I have to manage my BigDecimal values to avoid this issue:

  • Do not use the new BigDecimal(String) constructor and use directly the new BigDecimal(double)?
  • Force Oracle to use toPlainString() instead of toString() method when dealing with BigDecimal (and in this case how to do that)?
  • Any other solution?

Environment information:

  • Java 1.6.0_14
  • Hibernate 2.1.8 (yes, it is a quite old version)
  • Oracle JDBC 9.0.2.0 and also tested with 10.2.0.3.0
  • Oracle database 10.2.0.3.0

Edit : I've tested the same code in error but with the Oracle JDBC version 10.2.0.4.0 and the bug did not occur! The value stored was indeed 76,500,000.00... Regarding the changelog, maybe it is related to the bug #4711863.

+2  A: 

Confession: I don't personally use Hibernate, but could you just create a subclass MyBigDecimal whose toString() method calls toPlainString()?

I'm also not entirely sure of the merits of passing a double into the cosntructor of BigDecimal -- a double is inherently inaccurate unless the number is composed entirely of additions of powers of 2 (with range restrictions). The whole point of BigDecimal is to circumvent these restrictions on double.

Neil Coffey
Hmmm... It doesn't say it is final in the API. And it doesn't appear final for me. I was able to compile it against 1.6. Are you sure @Yishai?
Joseph Gordon
Joseph, you are right, I was going by memory. I was wrong.
Yishai
Juha's answer is the right way to go - you do *not* want to *ever* subclass a Java-defined type if you can help it - there is too much confusion when programmers decide to take it upon themselves to do this.
MetroidFan2002
+1  A: 

With modern Hibernate versions you can use UserType to map any class to a database field. Just make a custom UserType and use it to map BigDecimal object to database column.

See http://i-proving.ca/space/Technologies/Hibernate/User+Types+in+Hibernate

Juha Syrjälä