[JSR-354] Re: javax.money public review comments
- From: Werner Keil <werner.keil@...>
- To: "jcurrency_mail@..." <jcurrency_mail@...>
- Subject: [JSR-354] Re: javax.money public review comments
- Date: Wed, 27 Nov 2013 22:37:50 +0100
Thanks for the update. @Anatole, the string (potentially involving some
formatting) representation and online transfers are a good point. While it
seems country-specific, this Dutch GitHub project for SEPA transaction
using e.g. JAXB looks worth a closer visit:
Enjoy the Holidays,
On Wed, Nov 27, 2013 at 10:10 PM, roger riggs <roger.riggs@...>wrote:
> Hi Anatole,
> Thanks for the cogent recap.
> The issues around precision are relevant for developers and some
> description and
> guidance should be included in the API.
> As you describe it, the Money class facilitates a developer controlling
> and precision without the necessity of modifying all of their library code
> to use different types. That seems like a good basis for a single general
> purpose API with adequate performance.
> I'll have to take a closer look at the moneta packages after the short
> holidays here.
> Thanks, Roger
> On 11/26/2013 10:34 PM, Anatole Tresch wrote:
> Hi Roger
> the range of values were not specified explicitly AFAIK. We had more
> than one year of discussions on what would be an appropriate numeric
> representation of a monetary amount without consensus, what an appropriate
> numeric representation should be (so somehow these discussion are spread
> over the whole mail thread). Finally the decision was, to support multiple
> "flavors" of monetary amount types (basically using BD for high precision,
> and a long for fast performance). That is the reason that we have two
> implementations Money and FastMoney n the RI.
> Depending on your use case you choose the one that is matching best your
> Interoperability between them was modelled with the MonetaryAmount
> interface given so far (and the static *from *factory methods). As a
> recommendation it was stated in the spec, that creation of an amount (which
> is also happening when switching between different amount flavours) must
> throw an ArithmeticException, when the input number can not be mapped to
> the internal numeric representation (e.g. because it exceeds precision or
> Also we (re)used the existing numeric types from the JDK (BD, long), so
> we can explicitly inherit the concrete numeric capabilities of the JDK and
> so do not have to specify something new in this area. The Money class,
> currently based on BD, is still quite fast, since it is internally using
> MathContext.DECIMAL64 by default, instead of UNLIMITED (the long based
> variant, of course, is even faster). You can also override the default
> MathContext, on creation of the amount. The overall *default *MathContext
> can be also configured by adding a small properties file to the classpath.
> Finally the MathContext of an amount then is inherited to all results
> Given this two flavors we are able to cover almost every use case. The
> costly thing is switching between the flavors, which is expected to happen
> For accessing the numeric value, the *MonetaryAmout *interface does in
> fact this kind of tunneling (into 3 longs). But additionally there is also
> a method (though currently not on the interface)
> *public <T> T asType(Class<T> type);*
> which allows to access any type supported, including BD (if available in
> the current context), this method supports interoperability without having
> to use long/int. When looking for interoperability also with ME but also
> more, returning a String might even be an an option here, e.g. "19223.
> 3437465374". At least this is what typically is done, when passing
> amounts over the wire (in Corba, SOAP/REST, ISO20023 etc.).
> CHF 0.02, Anatole
> Your CHF .02 is worth more than my $.02.