Skip to main content

[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

Anatole/Roger/all,

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:
https://github.com/jasperkrijgsman/dutch-sepa-iso20022

Enjoy the Holidays,
Werner


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
> range
> 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
> needs.
> 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
> scale).
>
>  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
> returned.
>
>  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
> rarely.
>
>  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.
>
>


[JSR-354] Re: javax.money public review comments

(continued)

[JSR-354] Re: javax.money public review comments

Werner Keil 11/26/2013

[JSR-354] Re: javax.money public review comments

roger riggs 11/26/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/26/2013

[JSR-354] Re: javax.money public review comments

roger riggs 11/26/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/26/2013

[JSR-354] Re: javax.money public review comments

Stephen Colebourne 11/26/2013

[JSR-354] Re: javax.money public review comments

roger riggs 11/26/2013

[JSR-354] Re: javax.money public review comments

Anatole Tresch 11/27/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/27/2013

[JSR-354] Re: javax.money public review comments

roger riggs 11/27/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/27/2013

[JSR-354] Re: javax.money public review comments

Werner Keil 11/27/2013

[JSR-354] Re: javax.money public review comments

Sascha Freitag 11/26/2013
 
 
Close
loading
Please Confirm
Close