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 15:51:37 +0000

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] javax.money public review comments

roger riggs 11/25/2013

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

Anatole Tresch 11/25/2013

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

Werner Keil 11/25/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/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

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
 
 
Close
loading
Please Confirm
Close