Skip to main content

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

  • From: Anatole Tresch <atsticks@...>
  • To: Jsr 354 JavaMoney Public Mailinglist <jcurrency_mail@...>
  • Subject: [JSR-354] Re: javax.money public review comments
  • Date: Wed, 27 Nov 2013 04:34:33 +0100

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



2013/11/26 roger riggs <roger.riggs@...>

> Hi,
>
> I don't see in the descriptions of the use cases or the specification the
> requirements on the range of values. A 64 bit number seems sufficient for
> the use cases except where significantly higher precisions are needed.  In
> all cases exceptions would result for out of range values. To avoid
> rehashing them here, can I find in the email archives an analysis of the
> relative strengths and weaknesses?
>
> If the desire to access the number is significant then potential value
> type support will not help since the interface to familiar number types
> will have to be funneled through long or int.
>
> Roger
>
> p.s.
> avoid PARC: Error 33
>
>
> On 11/26/2013 12:55 PM, Stephen Colebourne wrote:
>
>> Unfortunately, the presence of absence of value types is key to the
>> project as money needs a number larger than 64 bits that performs
>> close to a primitive. With JSR-310 we managed with a long-int
>> combination (Instant/Duration) because there was little need to access
>> the number itself. With money, there is a much greater desire to
>> access the number. And since the amount is so key (money is one class
>> consisting of an amount and a currency) it will always be hard to
>> progress.
>>
>> Oracle as the manager of the JDK needs to decide whether they want a
>> JSR (usable by JDK 7 and later) or a JDK 9 API. I maintain that those
>> two are likely to result in different outcomes.
>>
>> My view is that there is no burning need for a JSR pre JDK 7 (as open
>> source libraries can handle this well). Thus the only need is for a
>> JDK API in JDK 9 (and if that is the case then a JSR may not even be
>> needed as a JEP would suffice).
>>
>> Stephen
>>
>>
>>
>> On 26 November 2013 16:42, roger riggs<roger.riggs@...>  wrote:
>>
>>> Hi,
>>>
>>> I expect that the value to developers and organizations should be high
>>> enough
>>> that it will be useful and valuable regardless of whether it can take
>>> advantage
>>> future JDK additions.
>>>
>>> Creating a dependency on a yet to be defined feature is one of the famous
>>> anti-patterns for projects. It would also inhibit use on earlier
>>> versions.
>>>
>>> Roger
>>>
>>>
>>>
>>> On 11/26/2013 10:51 AM, Stephen Colebourne wrote:
>>>
>>>> I mostly agree with Roger, but in a different way.
>>>>
>>>> I think that a group (either this JSR or something else) should define
>>>> a full API for JDK9, as per JSR-310, with concrete classes and
>>>> formatters to the fore. The interfaces proposed here are IMO only a
>>>> stopgap designed to serve apparant requirements pre-JDK 9 (that I do
>>>> not believe should be requirements). From my perspective the API is
>>>> neither large nor complex.
>>>>
>>>> Designing an API for JDK9 is relatively easy as it consists of just a
>>>> few classes. What is hard is that we do not yet know if the value type
>>>> language change will be in JDK 9 and what it will enable. Until we
>>>> know that, any effort on a JDK 9 only design is pretty moot.
>>>>
>>>> Stephen
>>>>
>>>>
>>>> On 26 November 2013 15:04, roger riggs<roger.riggs@...>  wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>   From my practical point of view, the API consists of the types,
>>>>> classes,
>>>>> methods that a developer uses on a daily basis.  Developers do not use
>>>>> frameworks, SPIs or implementation details unless the API fails them
>>>>> and
>>>>> by
>>>>> necessity they have to create their own more advanced functions or for
>>>>> integration. The API is used in sample code to validate that the use
>>>>> cases
>>>>> can be realized.
>>>>> Regardless of the terminology, the specification should be complete
>>>>> enough
>>>>> to describe to developers a closed set of types, methods, etc.
>>>>> sufficient
>>>>> and useful to solve currency manipulation and computation in the scope
>>>>> of
>>>>> the JSR.
>>>>>
>>>>> $.02, Roger
>>>>>
>>>>>
>>>>> On 11/26/2013 1:44 AM, Anatole Tresch wrote:
>>>>>
>>>>> Hi Roger
>>>>>
>>>>> that is clear so far. Discussions were much, if implementing classes
>>>>> like
>>>>> Money can be part of the so called "API", or summarizing there were
>>>>> different considerations what is an API in this context. Some see more
>>>>> only
>>>>> the interfaces and basic exceptions, deferring the rest to the
>>>>> implementation part, whereas from a perspective of a later inclusion
>>>>> into
>>>>> a
>>>>> JDK or value type semantics mentioned, also value type classes like
>>>>> Money
>>>>> then must be part of the API not the implementation. I think this is
>>>>> the
>>>>> core point where you might give as a hint.
>>>>>
>>>>> I the meantime I already extended the review period for another month.
>>>>> I
>>>>> expect that we will have good progress accommodating any changes
>>>>> required...
>>>>>
>>>>> Cheers,
>>>>> Anatole
>>>>>
>>>>>
>>>>>
>>>>> 2013/11/26 roger riggs<roger.riggs@...>
>>>>>
>>>>>> Hi Anatole,
>>>>>>
>>>>>> My highest priority is for an API that is complete and usable by
>>>>>> developers regardless of whether it becomes part of the JDK or not.
>>>>>> That means specifying the concrete API and making it
>>>>>> suitable at least for a common subset of the use cases.
>>>>>>
>>>>>> The EG has gathered expertise to define such an API.
>>>>>> Deferring to a future date or delegating to another team later
>>>>>> is not a good option.
>>>>>>
>>>>>> Given the holiday season is upon us, perhaps it would be
>>>>>> prudent to extend the review period  into January; with the
>>>>>> expectation that it will take some discussion to come to a
>>>>>> suitable new draft.  It the tasks seems too large, it may be possible
>>>>>> to withdraw the PR and resubmit later.
>>>>>>
>>>>>> Roger
>>>>>>
>>>>>>
>>>>>> On 11/25/2013 6:17 PM, Anatole Tresch wrote:
>>>>>>
>>>>>> Hi Roger/all
>>>>>>
>>>>>> thanks for your feedback. One large discussion we had in the EG was
>>>>>> about,
>>>>>> how the API should look like for later JDK inclusion. Since I felt
>>>>>> this
>>>>>> was
>>>>>> never clear I asked for feedback from Oracle already in May at the EC
>>>>>> meeting in Zurich. But finally I am glad, we have now some feedback
>>>>>> from
>>>>>> Oracle ;-)
>>>>>> Stephen Coleborne (@Stephen correct me where I am inprecise, or add
>>>>>> your
>>>>>> comments also ;-)) recommended, based on his experience with 310, to
>>>>>> reduce
>>>>>> the interface footprint. The objective was that developers must stick
>>>>>> on
>>>>>> the
>>>>>> concrete (value) classes for usage, similar to 310, where also users
>>>>>> will
>>>>>> typically never use TemporalUnit for example.
>>>>>> Readding a set of methods to the interfaces would be easy, since the
>>>>>> RI
>>>>>> already implements them, including tests, also defining an interface
>>>>>> and
>>>>>> some kind of accessor for the formatting part should also not be a big
>>>>>> thing.
>>>>>>
>>>>>> Can you give as a short hint, if that was your intention, also? I ask
>>>>>> this, because, I want to ensure that with the next update of the JSR,
>>>>>> we
>>>>>> catch up all things and have a common understanding within the EG as
>>>>>> well as
>>>>>> with Oracle.
>>>>>>
>>>>>> Summarizing we obviously have to extend the feedback period, since
>>>>>> this
>>>>>> feedback will have a significant impact on our JSR now.
>>>>>>
>>>>>> Cheers,
>>>>>> Anatole
>>>>>>
>>>>>>
>>>>>> 2013/11/25 roger riggs<roger.riggs@...>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have been busy with JDK 8 and unfortunately have not been able to
>>>>>>> participate actively.  I apologize for the lateness of these
>>>>>>> comments.
>>>>>>>
>>>>>>> The Public Review draft seems to over-correct for comments made on
>>>>>>> the
>>>>>>> Early Draft Review. The EDR may have been scoped too large and
>>>>>>> attempted to
>>>>>>> cover too many features but the public review draft in its current
>>>>>>> form
>>>>>>> does
>>>>>>> not cover the basic requirements of a usable currency API as outlined
>>>>>>> in the
>>>>>>> JSR proposal and that would be useful for developers.
>>>>>>>
>>>>>>> The Section 1.3 describes the reduction in scope but does not provide
>>>>>>> the
>>>>>>> rationale for omitting a concrete API. A minor detail, but it also
>>>>>>> mentions
>>>>>>> that simple formatting is in scope but an API is not included.
>>>>>>>
>>>>>>> The Core Requirements (3.1), seems to conclude that since no
>>>>>>> implementation is capable of supporting all aspects of the use cases
>>>>>>> therefore no concrete API is needed. But without a concrete API, the
>>>>>>> specification is of little use to developers.
>>>>>>>
>>>>>>> The specification of javax.money provides only interfaces but then
>>>>>>> says:
>>>>>>> "Users should not reference the interfaces, instead the value types
>>>>>>> should
>>>>>>> be used."
>>>>>>> The specification does not provide factories for the concrete value
>>>>>>> types, not even the simplest operations on currencies are part of the
>>>>>>> API
>>>>>>> (addition, subtraction). So the contents of the specification are not
>>>>>>> to be
>>>>>>> used by developers.  Javax.money specifies the means to interoperate
>>>>>>> between
>>>>>>> implementations but that is secondary, foremost needs to be a usable
>>>>>>> API to
>>>>>>> hold and operate on currency.
>>>>>>>
>>>>>>> On the plus side, the implementation packages in org.javamoney API
>>>>>>> include the essentials of the functions that a developer needs and a
>>>>>>> subset
>>>>>>> could be the basis for the standard javax.money API. Though it seems
>>>>>>> a
>>>>>>> bit
>>>>>>> heavyweight in places and has not been documented as a specification.
>>>>>>> For
>>>>>>> example, instead of three money classes, a single money class can be
>>>>>>> defined
>>>>>>> that supports a well defined range of amount and precision. Other
>>>>>>> implementations can address the more specialized use cases.
>>>>>>>
>>>>>>> JSR 354 should specify an API that meets the requirements in Section
>>>>>>> 3,
>>>>>>> and addresses the common elements of the use cases.
>>>>>>>
>>>>>>> Roger Riggs, Oracle Inc.
>>>>>>>
>>>>>>>  --
>>>>>> Anatole Tresch
>>>>>> Java Lead Engineer, JSR Spec Lead
>>>>>> Glärnischweg 10
>>>>>> CH - 8620 Wetzikon
>>>>>>
>>>>>> Switzerland, Europe Zurich, GMT+1
>>>>>> Twitter:  @atsticks
>>>>>> Blogs:http://javaremarkables.blogspot.ch/
>>>>>> Google: atsticks
>>>>>> Mobile  +41-76 344 62 79
>>>>>>
>>>>>>
>>>>>>  --
>>>>> Anatole Tresch
>>>>> Java Lead Engineer, JSR Spec Lead
>>>>> Glärnischweg 10
>>>>> CH - 8620 Wetzikon
>>>>>
>>>>> Switzerland, Europe Zurich, GMT+1
>>>>> Twitter:  @atsticks
>>>>> Blogs:http://javaremarkables.blogspot.ch/
>>>>> Google: atsticks
>>>>> Mobile  +41-76 344 62 79
>>>>>
>>>>>
>>>>>
>


-- 
*Anatole Tresch*
Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

*Switzerland, Europe Zurich, GMT+1*
*Twitter:  @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*

*Google: atsticksMobile  +41-76 344 62 79*


[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

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

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