DECIMAL implementations, J2ME and J2SE5 (tiger)

[Daniel John Debrunner <dj...@debrunners.com>]

-----BEGIN PGP SIGNED MESSAGE-----
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).
http://www.softwaresummit.com/2004/speakers/cowlishaw.htm

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.

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

iD8DBQFBlPxtIv0S4qsbfuQRAvLKAKC7ghuxymTEEQvOArKYz7UQIlA5UQCfTK8a
fjMfiTBxpIp92i6k9OpUuj0=
=wJil
-----END PGP SIGNATURE-----