Skip to main content

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

  • From: Stephen Colebourne <scolebourne@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: javax.money public review comments
  • Date: Tue, 26 Nov 2013 17:55:00 +0000

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
>>>
>>>
>


[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

Stephen Colebourne 11/26/2013

[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