Skip to main content

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

  • From: roger riggs <roger.riggs@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: javax.money public review comments
  • Date: Tue, 26 Nov 2013 11:42:33 -0500
  • Organization: Oracle Corporation

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

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

[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