[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.
On 26 November 2013 15:04, roger riggs <roger.riggs@...> wrote:
> 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...
> 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.
>> 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
>> 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
>> 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
>> with Oracle.
>> Summarizing we obviously have to extend the feedback period, since this
>> feedback will have a significant impact on our JSR now.
>> 2013/11/25 roger riggs <roger.riggs@...>
>>> 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
>>> cover too many features but the public review draft in its current form
>>> not cover the basic requirements of a usable currency API as outlined in
>>> 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
>>> 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
>>> used by developers. Javax.money specifies the means to interoperate
>>> implementations but that is secondary, foremost needs to be a usable API
>>> 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
>>> 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
>>> 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