Alternatives pour décimaux-précision arbitraire dans J2ME

Question

Nous faisons quelques modifications à un projet existant en utilisant J2ME. Jusqu'à présent, le nombre de décimales ont été traités comme des chaînes puisque aucune des opérations arithmétiques étaient nécessaires. Les valeurs ont été affichées uniquement sous forme de texte.

Maintenant, l'arithmétique de précision arbitraire est nécessaire. Si elle était Java SE, j'utiliser BigDecimal, mais ce n'est pas présent dans l'API MIDP / CLDC.

Je tente de travailler ma classe DecimalNumber personnalisée, mais alors que je fixais quelques bugs et découvrir de nouveaux dans les tests unitaires, je me suis aperçu qu'il obtiendra un peu de temps pour faire de cette roche solide classe et sans erreur.

Ainsi, au lieu de réinventer la roue, quelles alternatives pourrais-je réutiliser à cette fin? Par exemple, peuvent les classes BigInteger et BigDecimal être portés à J2ME (CLDC1.1)? Je l'ai lu sur d'autres question quelqu'un essayant de le BigDecimal de Port JavaSE avec BigInteger de bouncycastle. Sont-ils compatibles?

Toute aide sera appréciée.

Answer 1

Je porté avec succès la BigDecimal de JavaSE. Je devais le port aussi ces autres classes:

• Comparable
• Numéro
• BigInteger
• BitSieve
• MutableBigInteger
• SignedMutableBigInteger

En fait, je devais supprimer des génériques, des méthodes de sérialisation, presque toutes les méthodes de BigInteger liées à des nombres premiers, et remplacer int[].clone() avec une méthode similaire. peaufinage également les méthodes de compareTo.

Mon objectif était d'atteindre une précision arbitraire et convertir de chaîne à BigDecimal, je ne l'ai pas vraiment besoin de rien d'autre.

Mise à jour: ne fonctionne pas !!! Il semble que lors de la récupération du code source, j'ai mélangé les classes de différentes sources (celles provenaient OpenJDK, Oracle JavaSE, ...). Ceux-ci étaient pour Java 6, mais j'ai remarqué quelques changements importants entre les différentes versions de version. Il se trouve qu'ils ne sont pas bien Interopération (ou non certains d'entre eux contiennent des bogues sérieux, mais je ne le crois pas) pour que le port a été un grand échec. Il me faut un pour résoudre ce le plus tôt possible, alors maintenant je cherche les alternatives suivantes:

• Paypal a publié l'API de paiement mobile. La bibliothèque BlackBerry contient un port BigDecimal. Il n'est pas OpenSource, et les classes ont été brouillées, mais maintenant je peux dire qu'il fonctionne correctement. Seuls trois fichiers de classe sont nécessaires. Je pense qu'elle doit avoir été testé à fond, être stuff Paypal (je l'espère du moins).
• Il y a aussi SimpleBigDecimal de bouncycastle, mais il est pas aussi puissant que de Paypal ou de Java. Je me suis intéressé à avoir un constructeur String, qui cette classe ne fournit pas.
• Je suppose que le port de JavaSE serait plus facile en utilisant JavaSE v1.4.2. Comme il n'a pas Generics, il peut être plus rapide à développer, mais je suis réticent à aller pour cela parce que je pense que ces anciennes classes ne sont probablement pas aussi robuste que les plus récentes en 1,6 ou 1,7
• Je pourrais mettre en œuvre ma propre classe réduite à une échelle donnée (1 ou peut-être 2 décimales) et un ensemble de méthode réduite (comparer, ajouter et soustraire, essentiellement), mais vous savez, je voudrais avoir une solution plus générique et pas seulement une solution rapide.

MISE À JOUR:
J'ai finalement utilisé le port BigDecimal de PayPal contenu dans leur bibliothèque Paiement Mobility pour BlackBerry. BlackBerry est basé sur J2ME, il est donc parfait pour la tâche. Je l'ai fait une quantité considérable de tests unitaires sur elle et je peux dire qu'il est compatible avec le comportement de BigDecimal de JavaSE.

Answer 2

Avez-vous envisagé la mise en œuvre accrocs Harmony (voir ici )? Il faudra sans doute besoin d'un peu nettoyage car il est malheureusement pas sans générique, mais son là pour vous.