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 12:13:29 -0500
  • Organization: Oracle Corporation

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    <br>
    Interfaces are useful to define common and abstract semantics but
    they did not arrive by themselves and are not by themselves useful.<br>
    <br>
    I do not subscribe to your limited definition of Spec. Any well
    defined description of behavior is a specification.&nbsp; An
    implementation is itself a specification, though usually a bad one,
    failing to clearly indicate the invariants and assertions. The
    usefulness of interface vs implementation is only helpful if there
    are useful implementation characteristics and some reasonable
    mechanism for substitutability or evolution.<br>
    The design approach holding dear to concrete final classes provides
    a context in which there is no benefit to separation of interface
    from implementation. So the implementation is the spec or
    visa-versa.&nbsp; By design most projects have a mix of concrete and
    abstract, with the abstract providing interoperability and
    extensibility and the concrete being used on a daily basis to get
    real work done.<br>
    <br>
    I would focus more on producing a useful API for the whole community
    of developers and less on perceptions. A standardized currency API
    should be usable by Millions of developers and solve 80+ percent of
    their needs.&nbsp; An api that is designed for a few thousand developers
    has too narrow a target.<br>
    <br>
    In the context of JSR 354 what aspects of the implementation have
    been identified as being useful alternate implementations;
    performance is the usual obvious one.&nbsp; <br>
    Range and precision usually not.<br>
    <br>
    Regards, Roger<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/26/2013 11:06 AM, Werner Keil
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAAGawe0geVe861VS9iTcTGeKAuZ5npYkup50gRQq+_3zaXxZ=A@..."
      type="cite">
      <div dir="ltr">Not sure, if that is exactly what Roger meant?<img
          src="cid:part1.09060109.04010804@oracle.com" style="margin:
          0px 0.2ex; vertical-align: middle;" goomoji="35F">
        <div><br>
        </div>
        <div style="">Quite a lot of SE JSRs, Collection API, XML
          (Several "javax.xml" subpackages, especially "stream",
          "ws",...) or the new Lambda package in "java.util.function"
          consists of nothing but interfaces<img
            src="cid:part2.00040902.07040901@oracle.com" style="margin:
            0px 0.2ex; vertical-align: middle;" goomoji="329">&nbsp;Other
          notable SE "Specs" would be the whole Annotation or Enum
          mechanism.</div>
        <div style=""><br>
        </div>
        <div style="">JSR-310 is not a true Spec compared to these as it
          has too many cross-references to its own RI or isolated
          lone-man approaches e.g. tor formatting. Whether or not Oracle
          wants this as a general direction or a more consistent
          approach, especially to formatting, we may have to ask the
          likes of Brian Goetz or Mark Reinhold. Roger hopefully has an
          opinion, too.&nbsp;</div>
        <div style=""><br>
        </div>
        <div style="">Werner</div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Tue, Nov 26, 2013 at 4:51 PM,
            Stephen Colebourne <span dir="ltr">&lt;<a
                moz-do-not-send="true"
                href="mailto:scolebourne@..."; target="_blank">scolebourne@...</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">I mostly
              agree with Roger, but in a different way.<br>
              <br>
              I think that a group (either this JSR or something else)
              should define<br>
              a full API for JDK9, as per JSR-310, with concrete classes
              and<br>
              formatters to the fore. The interfaces proposed here are
              IMO only a<br>
              stopgap designed to serve apparant requirements pre-JDK 9
              (that I do<br>
              not believe should be requirements). From my perspective
              the API is<br>
              neither large nor complex.<br>
              <br>
              Designing an API for JDK9 is relatively easy as it
              consists of just a<br>
              few classes. What is hard is that we do not yet know if
              the value type<br>
              language change will be in JDK 9 and what it will enable.
              Until we<br>
              know that, any effort on a JDK 9 only design is pretty
              moot.<br>
              <span class="HOEnZb"><font color="#888888"><br>
                  Stephen<br>
                </font></span>
              <div class="HOEnZb">
                <div class="h5"><br>
                  <br>
                  On 26 November 2013 15:04, roger riggs &lt;<a
                    moz-do-not-send="true"
                    href="mailto:roger.riggs@...";>roger.riggs@...</a>&gt;
                  wrote:<br>
                  &gt; Hi,<br>
                  &gt;<br>
                  &gt; From my practical point of view, the API consists
                  of the types, classes,<br>
                  &gt; methods that a developer uses on a daily basis.
                  &nbsp;Developers do not use<br>
                  &gt; frameworks, SPIs or implementation details unless
                  the API fails them and by<br>
                  &gt; necessity they have to create their own more
                  advanced functions or for<br>
                  &gt; integration. The API is used in sample code to
                  validate that the use cases<br>
                  &gt; can be realized.<br>
                  &gt; Regardless of the terminology, the specification
                  should be complete enough<br>
                  &gt; to describe to developers a closed set of types,
                  methods, etc. sufficient<br>
                  &gt; and useful to solve currency manipulation and
                  computation in the scope of<br>
                  &gt; the JSR.<br>
                  &gt;<br>
                  &gt; $.02, Roger<br>
                  &gt;<br>
                  &gt;<br>
                  &gt; On 11/26/2013 1:44 AM, Anatole Tresch wrote:<br>
                  &gt;<br>
                  &gt; Hi Roger<br>
                  &gt;<br>
                  &gt; that is clear so far. Discussions were much, if
                  implementing classes like<br>
                  &gt; Money can be part of the so called "API", or
                  summarizing there were<br>
                  &gt; different considerations what is an API in this
                  context. Some see more only<br>
                  &gt; the interfaces and basic exceptions, deferring
                  the rest to the<br>
                  &gt; implementation part, whereas from a perspective
                  of a later inclusion into a<br>
                  &gt; JDK or value type semantics mentioned, also value
                  type classes like Money<br>
                  &gt; then must be part of the API not the
                  implementation. I think this is the<br>
                  &gt; core point where you might give as a hint.<br>
                  &gt;<br>
                  &gt; I the meantime I already extended the review
                  period for another month. I<br>
                  &gt; expect that we will have good progress
                  accommodating any changes required...<br>
                  &gt;<br>
                  &gt; Cheers,<br>
                  &gt; Anatole<br>
                  &gt;<br>
                  &gt;<br>
                  &gt;<br>
                  &gt; 2013/11/26 roger riggs &lt;<a
                    moz-do-not-send="true"
                    href="mailto:roger.riggs@...";>roger.riggs@...</a>&gt;<br>
                  &gt;&gt;<br>
                  &gt;&gt; Hi Anatole,<br>
                  &gt;&gt;<br>
                  &gt;&gt; My highest priority is for an API that is
                  complete and usable by<br>
                  &gt;&gt; developers regardless of whether it becomes
                  part of the JDK or not.<br>
                  &gt;&gt; That means specifying the concrete API and
                  making it<br>
                  &gt;&gt; suitable at least for a common subset of the
                  use cases.<br>
                  &gt;&gt;<br>
                  &gt;&gt; The EG has gathered expertise to define such
                  an API.<br>
                  &gt;&gt; Deferring to a future date or delegating to
                  another team later<br>
                  &gt;&gt; is not a good option.<br>
                  &gt;&gt;<br>
                  &gt;&gt; Given the holiday season is upon us, perhaps
                  it would be<br>
                  &gt;&gt; prudent to extend the review period &nbsp;into
                  January; with the<br>
                  &gt;&gt; expectation that it will take some discussion
                  to come to a<br>
                  &gt;&gt; suitable new draft. &nbsp;It the tasks seems too
                  large, it may be possible<br>
                  &gt;&gt; to withdraw the PR and resubmit later.<br>
                  &gt;&gt;<br>
                  &gt;&gt; Roger<br>
                  &gt;&gt;<br>
                  &gt;&gt;<br>
                  &gt;&gt; On 11/25/2013 6:17 PM, Anatole Tresch wrote:<br>
                  &gt;&gt;<br>
                  &gt;&gt; Hi Roger/all<br>
                  &gt;&gt;<br>
                  &gt;&gt; thanks for your feedback. One large
                  discussion we had in the EG was about,<br>
                  &gt;&gt; how the API should look like for later JDK
                  inclusion. Since I felt this was<br>
                  &gt;&gt; never clear I asked for feedback from Oracle
                  already in May at the EC<br>
                  &gt;&gt; meeting in Zurich. But finally I am glad, we
                  have now some feedback from<br>
                  &gt;&gt; Oracle ;-)<br>
                  &gt;&gt; Stephen Coleborne (@Stephen correct me where
                  I am inprecise, or add your<br>
                  &gt;&gt; comments also ;-)) recommended, based on his
                  experience with 310, to reduce<br>
                  &gt;&gt; the interface footprint. The objective was
                  that developers must stick on the<br>
                  &gt;&gt; concrete (value) classes for usage, similar
                  to 310, where also users will<br>
                  &gt;&gt; typically never use TemporalUnit for example.<br>
                  &gt;&gt; Readding a set of methods to the interfaces
                  would be easy, since the RI<br>
                  &gt;&gt; already implements them, including tests,
                  also defining an interface and<br>
                  &gt;&gt; some kind of accessor for the formatting part
                  should also not be a big<br>
                  &gt;&gt; thing.<br>
                  &gt;&gt;<br>
                  &gt;&gt; Can you give as a short hint, if that was
                  your intention, also? I ask<br>
                  &gt;&gt; this, because, I want to ensure that with the
                  next update of the JSR, we<br>
                  &gt;&gt; catch up all things and have a common
                  understanding within the EG as well as<br>
                  &gt;&gt; with Oracle.<br>
                  &gt;&gt;<br>
                  &gt;&gt; Summarizing we obviously have to extend the
                  feedback period, since this<br>
                  &gt;&gt; feedback will have a significant impact on
                  our JSR now.<br>
                  &gt;&gt;<br>
                  &gt;&gt; Cheers,<br>
                  &gt;&gt; Anatole<br>
                  &gt;&gt;<br>
                  &gt;&gt;<br>
                  &gt;&gt; 2013/11/25 roger riggs &lt;<a
                    moz-do-not-send="true"
                    href="mailto:roger.riggs@...";>roger.riggs@...</a>&gt;<br>
                  &gt;&gt;&gt;<br>
                  &gt;&gt;&gt; Hi,<br>
                  &gt;&gt;&gt;<br>
                  &gt;&gt;&gt; I have been busy with JDK 8 and
                  unfortunately have not been able to<br>
                  &gt;&gt;&gt; participate actively. &nbsp;I apologize for
                  the lateness of these comments.<br>
                  &gt;&gt;&gt;<br>
                  &gt;&gt;&gt; The Public Review draft seems to
                  over-correct for comments made on the<br>
                  &gt;&gt;&gt; Early Draft Review. The EDR may have been
                  scoped too large and attempted to<br>
                  &gt;&gt;&gt; cover too many features but the public
                  review draft in its current form does<br>
                  &gt;&gt;&gt; not cover the basic requirements of a
                  usable currency API as outlined in the<br>
                  &gt;&gt;&gt; JSR proposal and that would be useful for
                  developers.<br>
                  &gt;&gt;&gt;<br>
                  &gt;&gt;&gt; The Section 1.3 describes the reduction
                  in scope but does not provide the<br>
                  &gt;&gt;&gt; rationale for omitting a concrete API. A
                  minor detail, but it also mentions<br>
                  &gt;&gt;&gt; that simple formatting is in scope but an
                  API is not included.<br>
                  &gt;&gt;&gt;<br>
                  &gt;&gt;&gt; The Core Requirements (3.1), seems to
                  conclude that since no<br>
                  &gt;&gt;&gt; implementation is capable of supporting
                  all aspects of the use cases<br>
                  &gt;&gt;&gt; therefore no concrete API is needed. But
                  without a concrete API, the<br>
                  &gt;&gt;&gt; specification is of little use to
                  developers.<br>
                  &gt;&gt;&gt;<br>
                  &gt;&gt;&gt; The specification of javax.money provides
                  only interfaces but then says:<br>
                  &gt;&gt;&gt; "Users should not reference the
                  interfaces, instead the value types should<br>
                  &gt;&gt;&gt; be used."<br>
                  &gt;&gt;&gt; The specification does not provide
                  factories for the concrete value<br>
                  &gt;&gt;&gt; types, not even the simplest operations
                  on currencies are part of the API<br>
                  &gt;&gt;&gt; (addition, subtraction). So the contents
                  of the specification are not to be<br>
                  &gt;&gt;&gt; used by developers. &nbsp;Javax.money
                  specifies the means to interoperate between<br>
                  &gt;&gt;&gt; implementations but that is secondary,
                  foremost needs to be a usable API to<br>
                  &gt;&gt;&gt; hold and operate on currency.<br>
                  &gt;&gt;&gt;<br>
                  &gt;&gt;&gt; On the plus side, the implementation
                  packages in org.javamoney API<br>
                  &gt;&gt;&gt; include the essentials of the functions
                  that a developer needs and a subset<br>
                  &gt;&gt;&gt; could be the basis for the standard
                  javax.money API. Though it seems a bit<br>
                  &gt;&gt;&gt; heavyweight in places and has not been
                  documented as a specification. &nbsp;For<br>
                  &gt;&gt;&gt; example, instead of three money classes,
                  a single money class can be defined<br>
                  &gt;&gt;&gt; that supports a well defined range of
                  amount and precision. Other<br>
                  &gt;&gt;&gt; implementations can address the more
                  specialized use cases.<br>
                  &gt;&gt;&gt;<br>
                  &gt;&gt;&gt; JSR 354 should specify an API that meets
                  the requirements in Section 3,<br>
                  &gt;&gt;&gt; and addresses the common elements of the
                  use cases.<br>
                  &gt;&gt;&gt;<br>
                  &gt;&gt;&gt; Roger Riggs, Oracle Inc.<br>
                  &gt;&gt;&gt;<br>
                  &gt;&gt;<br>
                  &gt;&gt;<br>
                  &gt;&gt;<br>
                  &gt;&gt; --<br>
                  &gt;&gt; Anatole Tresch<br>
                  &gt;&gt; Java Lead Engineer, JSR Spec Lead<br>
                  &gt;&gt; Gl&auml;rnischweg 10<br>
                  &gt;&gt; CH - 8620 Wetzikon<br>
                  &gt;&gt;<br>
                  &gt;&gt; Switzerland, Europe Zurich, GMT+1<br>
                  &gt;&gt; Twitter: &nbsp;@atsticks<br>
                  &gt;&gt; Blogs: <a moz-do-not-send="true"
                    href="http://javaremarkables.blogspot.ch/";
                    target="_blank">http://javaremarkables.blogspot.ch/</a><br>
                  &gt;&gt; Google: atsticks<br>
                  &gt;&gt; Mobile &nbsp;<a moz-do-not-send="true"
                    href="tel:%2B41-76%20344%2062%2079"
                    value="+41763446279">+41-76 344 62 79</a><br>
                  &gt;&gt;<br>
                  &gt;&gt;<br>
                  &gt;<br>
                  &gt;<br>
                  &gt;<br>
                  &gt; --<br>
                  &gt; Anatole Tresch<br>
                  &gt; Java Lead Engineer, JSR Spec Lead<br>
                  &gt; Gl&auml;rnischweg 10<br>
                  &gt; CH - 8620 Wetzikon<br>
                  &gt;<br>
                  &gt; Switzerland, Europe Zurich, GMT+1<br>
                  &gt; Twitter: &nbsp;@atsticks<br>
                  &gt; Blogs: <a moz-do-not-send="true"
                    href="http://javaremarkables.blogspot.ch/";
                    target="_blank">http://javaremarkables.blogspot.ch/</a><br>
                  &gt; Google: atsticks<br>
                  &gt; Mobile &nbsp;<a moz-do-not-send="true"
                    href="tel:%2B41-76%20344%2062%2079"
                    value="+41763446279">+41-76 344 62 79</a><br>
                  &gt;<br>
                  &gt;<br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

Attachment: gifITzwYbeBse.gif
Description: GIF image

Attachment: gifC7Tb57bsFV.gif
Description: GIF image



[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

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