-----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-----
