I asked Lance Anderson, spec lead for JDBC 4.0, about this issue and he replied that he thinks that due to compatibility with existing applications that rely on this behavior, it's unlikely to change.

My opinion is that the behavior is surprising, and that most applications that discover that the API with a  BigDecimal parameter truncates all the decimals, simply change to the API call that allows you to specify the scale. 

So my big unfounded claim is that there is no use for the API without the scale parameter taking a BigDecimal parameter with the current behavior. And that changing it has low risk of untoward results.


On Jan 5, 2006, at 5:21 AM, Thomas Dudziak wrote:

On 1/4/06, Bernt M. Johnsen <Bernt.Johnsen@sun.com> wrote:

I was too fast in my conclusions. It is not a bug.

setObject(idx, bigDecimal, Types.NUMERIC) is defined to be identical
with setObject(idx, bigDecimal, Types.NUMERIC, 0) and that's exactly
what Derby does.

If you need decimals, you have to specify scale. E.g.:

setObject(idx, new BigDecimal("0.9999"), Type.NUMERIC, 4);

Indeed, you're right (though I think this is a design error in JDBC
itself). I've changed my source accordingly (using setBigDecimal


Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!