[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 16:32:15 +0100
Thanks, much apprecited.
While extended parts of the API including Regions, etc. probably should
remain with JavaMoney modules (where each of them can be selected by
demand) currency manipulation and computation probably should go back into
API parts like MonetaryAmount. To a reasonable extent, i.E. even the fairly
restrictive JSR 310 API (the stuff in "temporal" mostly) provides a couple
of methods like add() or multiply() that its equivalents in JSR 354 have
been stripped of.
@Roger would you recommend even things like Currency Conversion, or do you
feel the most basic functional interfaces like MonetaryOperator in the API
are sufficient? It is used also in Conversion classes either in the Moneta
RI or JavaMoney Libraries now.
Same to formatting. A very basic formatter somewhere along the lines of
this Unit-API interface:
be worth a thought. On the other hand, you may know best how bad it looks
for JSR 310:
for some of the enum types defining styles, there is not a single
"specification" and worse, a DecimalStyle
and final class handles numeric formatting in a completely different,
isolated way inconsistent with anything either *java.text *and its Format
support provides or even *java.util.Formatter *and *java.util.Formattable*,
the latter did receive a Lambda update with Java 8, too btw. so it may be a
The Formatter doc
http://download.java.net/jdk8/docs/api/java/util/Formatter.html is of
course mess and confusing to most developers, so I can't fully blame
Stephen for trying to avoid it, but on Oracle's side it is a bad thing to
fragment the whole formatting and i18n business by allowing individual JSRs
their own little DecimalFormat. What should JSR 354 do, jump the same cliff?
On Tue, Nov 26, 2013 at 4:04 PM, 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
>> 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
>> 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.
>> 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
>>> 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
>>> 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
>>> 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 <%2B41-76%20344%2062%2079>*
> *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 <%2B41-76%20344%2062%2079>*
Description: GIF image