db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: JSR169 support
Date Fri, 08 Oct 2004 17:25:30 GMT
Hash: SHA1

Jan Hlavaty wrote:

> Daniel John Debrunner wrote:
>>Daniel John Debrunner wrote:
>>Classes missing causing compile errors
>>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:

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.

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


View raw message