Skip to main content

[JSR-354] Further Feedback on the API

  • From: Anatole Tresch <atsticks@...>
  • To: Jsr 354 JavaMoney Public Mailinglist <jcurrency_mail@...>
  • Cc: Mark Davis <mark@...>, David Beaumont <dbeaumont@...>
  • Subject: [JSR-354] Further Feedback on the API
  • Date: Thu, 10 Oct 2013 00:44:21 +0200

Dear all

having a long talk with Mark Davis and David Beaumont from Google there is
some valuable feedback, which is worth to be included/discussed:


   - *(1) MonetaryAdjusters and Queries should be immutable, *Especially
   when looking at usage with Lambdas in Java 8 it might be worth to remove
   the recommendation, and require immutability.
   - (2) We should *clearer define, that the numeric values on the
   MonetaryAmount i*nterface are meant for* interoperability/interchange
   only*.
   - (3) Additionally if the numeric value stored within the instance, *what
   should happen, if the amount should be converted into the whole/nom/denom
   values, but it does not fit (truncation would be required)?* There are
   different solutions possible
      - allow implicit truncation (not really a solution!)
      - add additional methods for getAmountWhole(boolean),
      getFractionNominator(boolean), where the boolean allows explcitily the
      returned value to be truncated, if it does not fit.
      - In all cases, if truncation is not allowed (by default, or by
      passing false), an ArithmeticException should be thrown.
      - Regarding the above scenarios, it was also discussed, if we should
      define some Rational type, so we can more easily apply the boolean, by
      replacing the methods with
         - Rational getNumericValue(); // truncating false
         - Rational getNumericValue(boolean allowTruncatingWhole, boolean
         allowTruncatingNominator);
      - (4) Finally,* we should add some additional constraints on the
   numric representation parts* such as, given the amountWhole=w,
   nominator=n, denominator=d, the following must be true
      - !(w<0 && n>0)
      - !(w>0 && n<0)
      - abs(n) < d¨
      - d>0

          This would simplify the conversion logic and also prevent from
some pitfalls.

   - (5) Also discussed was slightly alternative representation variant,
   where
      - we add an additional method
         boolean isNegative()
      - hereby then
         - w >= 0
         - n >=0
         - n < d
         - d > 0

So your feedback is required to each of the points above!

Cheers,
Anatole

-- 
*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] Further Feedback on the API

Anatole Tresch 10/09/2013

[JSR-354] Re: Further Feedback on the API

Stephen Colebourne 10/10/2013

[JSR-354] Re: Further Feedback on the API

Werner Keil 10/10/2013

[JSR-354] Re: Further Feedback on the API

Stephen Colebourne 10/10/2013

[JSR-354] Re: Further Feedback on the API

Tresch, Anatole (KGVA 55) 10/10/2013

[JSR-354] Re: Further Feedback on the API

Werner Keil 10/10/2013
 
 
Close
loading
Please Confirm
Close