db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject DECIMAL implementations, J2ME and J2SE5 (tiger)
Date Fri, 12 Nov 2004 18:09:49 GMT
Hash: SHA1

After going to Mike Cowlishaw's presentation on J2SE 5 (tiger)
BigDecimal at the Colorado Software Summit I realised that Derby will
need to implement the DECIMAL datatype in three ways (maybe two).

J2ME/OSGi - Derby specific code (no BigDecimal support)

J2SE 1.3, 1.4 - java.math.BigDecimal

J2SE 5.0 (and beyond) - java.math.BigDecimal with MathContext (new
features in tiger)

It's possible that J2SE 1.3, 1.4 could use the J2ME support, but it will
depend on performance and if that becomes a limited implementation.

There are two reasons that we do not want to just use the lowest common
denominator for all:

  1) The new features of BigDecimal in tiger support arithmetic without
an ever growing precision, basically the current BigDecimal
specification means that the result of an operation such as multiply
will double the byte size of the result as it has an unlimited precision
model. The new MathContext allows the result to be precision constrained.

  2) Decimal arithmetic hardware is right around the corner, and the
Java JIT's will be able to take BigDecimal method calls and map them to
hardware instructions, greatly improving performance. Mike's team has
run a standard Java benchmark that is defined to use floating point and
converted it to use Java BigDecimal (as the real world would have to
do). The result (without decimal hardware) was shocking, the transaction
rate dropped from around 3,862 orders/second to 1,193.

Thus as I factor out the Derby DECIMAL support for J2ME/OSGi, I will
ensure that the framework can support the J2SE 5.0 enhancements.

Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message