Skip to main content

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

  • From: Werner Keil <werner.keil@...>
  • To: "jcurrency_mail@javamoney java. net" <jcurrency_mail@...>
  • Subject: [JSR-354] Re: javax.money public review comments
  • Date: Wed, 27 Nov 2013 06:01:51 +0100

Should work like a simple
T get()
approach by the Java 8 Supplier, too.

If the interface and Implementations require even dynamically changing
value types to return (as long as the class is known at time of the call
and compatible with the return value;-) with each call, that could (and
should) also be backed by a "Lambdaesque" functional interface, given there
seems no equivalent to that in Java8.

Maybe if we define it in the JSR it's worth considering for Java 9, too?;-)
Am 27.11.2013 04:35 schrieb "Anatole Tresch" <atsticks@...>:

> 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 <%2B41-76%20344%2062%2079>*
>


[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

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