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: Tue, 26 Nov 2013 18:02:45 +0100

Hi,

Thanks a lot Roger for the input and clarification. I suppose the timeline
for an extension of the current Public Review seems fine as Anatole
communicated it with PMO, the ballot would in that case end about 2 weeks
before a scheduled JUG Summit and EC F2F Meeting at Oracle HQ next January.
Do you expect to participate in any of these?
It may be a good opportunity to have a chat, not necessarily in the actual
F2F, also with some of the new EC members from JUGs like Moroccco where
Mohamed AFAIK asked to join the EG as a true Individual (and hopefully by
then PMO bureaucracy may be done with it?[?])

Werner


On Tue, Nov 26, 2013 at 5:42 PM, 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
>>>
>>>
>>>
>

Attachment: 329.gif
Description: GIF image



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

(continued)

[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

[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