[JSR-354] Re: Further Feedback on the API
- From: Stephen Colebourne <scolebourne@...>
- To: jcurrency_mail@...
- Cc: Mark Davis <mark@...>, David Beaumont <dbeaumont@...>
- Subject: [JSR-354] Re: Further Feedback on the API
- Date: Thu, 10 Oct 2013 15:10:24 +0100
On 9 October 2013 23:44, Anatole Tresch <atsticks@...> wrote:
> (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.
JSR-310 says "This interface places no restrictions on the mutability
of implementations, however immutability is strongly recommended."
This seems like a reasonable balance for a mutable lanuage like Java.
Its unlikely that many will write mutable functions, and if they do
then that is their problem. The interface certainly cannot enforce
> (2) We should clearer define, that the numeric values on the MonetaryAmount
> interface are meant for interoperability/interchange only.
Explaining the purpose of a design is a good thing for package-info.java.
> (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.
We should allow truncation or ArithmeticException at the implementors
choice. No boolean flags!
> 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
The whole JSR revolves around the numeric type here. The current
proposal is a simple option that covers most reasonable use cases. If
Java had a Rational class we might use that. Or a faster Decimal
class/primitive. Or a 128-bit primitive integer.
Some in Oracle may push the JSR to use BigDecimal, which I feel would
be a constraint (one that JSR-310 avoided).
FWIW, I don't think the JSR can define its own Rational class and then
be included in the JDK, as the Rational class would likely want to be
in java.util as it is beyond just money.
> (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¨
> This would simplify the conversion logic and also prevent from
> some pitfalls.
I agree with those four if I understand them correctly.
- sign of whole and numerator must match (unless one or both is zero)
- numerator is less than denominator
- denominator is greater than zero
> (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
I think that would be more confusing. I expect some users will just
want the whole part ignoring fractions, and those users should get a
BTW, the Javadoc/spec should reserve the method name getAmount(). That
allows the JDK integration to add a default method returning
BigDecimal/Rational if the JDK adds it.