Alternatives for arbitrary-precision decimals in J2ME

567 views Asked by At

We're making some modifications to a legacy project using J2ME. Until now, decimal numbers were treated as Strings since no arithmetic operations were needed. The values were only displayed as text.

Now, arbitrary-precision arithmetic is required. If it were Java SE, I'd use BigDecimal, but it is not present in the MIDP/CLDC API.

I was trying to work out my custom DecimalNumber class, but while I was fixing some bugs and discovering new ones in the unit tests, I realized that it will get some time to make this class rock-solid and error-free.

So, instead of reinventing the wheel, what alternatives could I reuse for this purpose? For instance, can the BigInteger and BigDecimal classes be ported to J2ME (CLDC1.1)? I've read on other question someone trying to port JavaSE's BigDecimal with bouncycastle's BigInteger. Are these compatible?

Any help will be appreciated.

2

There are 2 answers

0
Mister Smith On BEST ANSWER

I successfully ported JavaSE's BigDecimal. I had to port also these other classes:

  • Comparable
  • Number
  • BigInteger
  • BitSieve
  • MutableBigInteger
  • SignedMutableBigInteger

Basically I had to remove generics, some serialization methods, almost every method in BigInteger related to primes, and replace int[].clone() with a similar method. Also tweaking the compareTo methods.

My goal was just to achieve arbitrary-precision and convert from String to BigDecimal, I didn't really need anything else.

UPDATE: Not working!!! Seems that when retrieving the source code, I mixed classes from different sources (ones were from OpenJDK, Oracle JavaSE, ...). These were all for Java 6, but I've noticed some major changes between different version releases. It turns out that they are not interoperating well (or either some of them contain serious bugs, but I don't think so) so the port has been a BIG fail. I need a to solve this ASAP, so now I'm looking for the following alternatives:

  • Paypal has released the Mobile Payment API. The BlackBerry library contains a BigDecimal port. It is not OpenSource, and the classes have been obfuscated, but as to now I can say it is working properly. Only three class files are needed. I expect it to have been thoroughly tested, being Paypal's stuff (at least I hope so).
  • There's also bouncycastle's SimpleBigDecimal, but it is not as powerful as Paypal's or Java's. I was interested in having a String constructor, which this class doesn't provide.
  • I guess the port from JavaSE would be easier using JavaSE v1.4.2. As it doesn't have Generics, it may be faster to develop, but I'm reluctant to go for this because I think these old classes probably are not as robust as the newer ones in 1.6 or 1.7
  • I could implement my own reduced class for a given scale (1 or maybe 2 decimals) and a reduced method set (compare, add and substract, basically), but you know, I'd like to have a more generic solution and not just a quick workaround.

UPDATE:
I finally used PayPal's BigDecimal port contained in their Mobility Payment Library for BlackBerry. BlackBerry is based on J2ME, so it is perfect for the task. I've made a considerable amount of unit tests on it and I can say that it is consistent with the behavior of JavaSE's BigDecimal.

1
Femi On

Have you considered snagging the Harmony implementation (see here)? It will probably need some clean up as it is unfortunately NOT generic-free, but its out there for you.