-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Hlavaty wrote:
> Daniel John Debrunner wrote: > >>Daniel John Debrunner wrote: >>Classes missing causing compile errors >> >>java.math.BigDecimal > > >>DECIMAL datatype >> I think this datatype needs to be supported under JSR169 though how, >>is less clear. > > > We could pack standalone version of BigDecimal, like this: > > http://oss.software.ibm.com/cvs/icu4j/icu4j/src/com/ibm/icu/math/?only_with_tag=HEAD I think that's the general approach but we need to go further. That class depends on java.math.BigInteger which is in CDC/Foundation but is not in OSGi ee.minimum. I think we can take advantage of the fact that Derby limits DECIMAL to 31 precision to implement a simpler "BigDecimal". The real BigDecimal has to handle precision up to max int. Also Derby does not need to support all the methods of BigDecimal. It may turn out that a specialized implementation would be faster than Derby's current use of BigDecimal, since BigDecimal is immutable and each BigDecial requires three object creations. E.g. for a query like select price * tax from items where ... there will be a lot of object creation in the current Derby implementation. I've been messing with some initial ideas on using long primitive to perform the operations, that just handles up to around DECIMAL(20), while still storing in the format defined by BigDecimal/BigInteger. If I can hack it into Derby I might try to run some performance tests. Any initial hack I'm doing might ignore tricky issues like over/under flow and division. I just want to get an idea to see if the performance benefit is worth it for J2SE. Or maybe there is other code out there that performs fixed point arithmetic using one or two longs internally. Dan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBZs2KIv0S4qsbfuQRAskJAKCCIn4HaL5hHrdQ9K9MjqTkgb+/8ACgq2G9 3eXRvCyZR4zW+kbVtNKsFwM= =Md06 -----END PGP SIGNATURE-----
