Skip to main content

[JSR-354] Re: Type of MonetaryAmount

  • From: Sascha Freitag <dunschtig@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Type of MonetaryAmount
  • Date: Sun, 28 Jul 2013 21:59:25 +0200

Hi all,

for me such a typing goes also beyond what I would look for in such an API.

Cheers Sascha
On 14.07.2013 18:16, Werner Keil wrote:

I rephrased the subject, as it was derived from the other discussion, but at least the idea of an AmountType seems not directly related.

Type examples like "MIN_SALARY" or others feel a bit like those attributes or properties we had in disguise.

javamoney-extras got a few types like CompoundType or MultiValue. And having "fields" or any sort of user-defined sub-fraction, I am not sure, if this belongs to a single MonetaryAmount.

Which is why I don't feel comfortable with the 2c which suggests a monetary amount could be split into fields like "MIN_SALARY", "VAT" or similar.
If on the other hand there was a need for classification somewhat similar to the ExchangeRate Type, where you may put a series of MonetaryAmount values into either just a simple collection or something like an "invoice" and such AmountType allows retrieving and filtering all amounts of type "VAT" or any other type, I could see value, but I'm not sure, if that'll breach the boundary between general purpose API and custom application code in some cases.

More opinions welcome,


On Sun, Jul 14, 2013 at 1:25 PM, Anatole Tresch <atsticks@... <mailto:atsticks@...>> wrote:

    Hi all

    along the discussion on amounts, I would like to add an additional
    point, which may be interesting. Often, when we are working with
    amounts, or passing them around in our logic, an "amount is not an
    amount", meaning that it would be a big advantage, when we would
    be able to classify amounts using something like an amount type.
    Also when working with collections of amounts according functions
    (FunctionalInterface)  passed to such collections can also easily
    benefit from such a feature.

    Basically I would see two main options, how we could model this

    1) For both variants we define an additional AmountTypeclass,
    similar to ExchangeRate type.
    2a) We extend the current MonetaryAmount with the AmountType. If
    not set explcitly, it is set to AmountType.UNDEFINED.
    hereby a result of a monetary operation also automatically
    appliesAmountType.UNDEFINED to its result. AmountType itself
    implements MonetaryFunction, so the amounts type can easily be set
    MonetaryAmount ma =...; ma.with(AmountType.of("MIN_SALARY"));
    2b) The same is basically also possible by adding a
    TypedMonetaryAmount wrapper, which then can be instantiated using
    an amount: TypedMonetaryAmount ta = TypedMonetaryAmount.of(ma,
     But there is one big disadvantage, when using a wrapper:
    MonetaryFunction implementations can not use them, without having
    to check if it can be cast to TypedMonetaryAmount.
    2c) One additional variant can also be to introduce fields, a bit
    similar to what Stephen Colebourne proposed, so we can provide
    such additional information in format of a field accessor:
    AmountType type = ma.getField(MonetaryAmount.AmountType);

    I personally prefer solution 2a, since its only a minor extension,
    but allows the feature without constraint be used by
    MonetaryFunction implementations...

    So as you see, there are a couple of ideas, but I think we have to
    further discuss it. Nevertheless I think that such a type
    extension would be very important and also, similar to strongly
    typed languages, allows to avoid cumbersome errors, since amounts
    can be mixed.


    2013/7/14 tom.huesler@... <mailto:tom.huesler@...>
    <tom.huesler@... <mailto:tom.huesler@...>>

        I agree with chris that on the multiplications its
        confusing... You dont multiply a Monetary value with another
        but with a natural number....semantically it doesn't seem
        correct to multiply / divide two monetary values.

        So in my opinion it should be
        .... The other signature i would likely drop.

        Also I'am not sure if the add(number) really makes sense from
        a semantical point...

        On 13.07.2013, at 16:57, Werner Keil <werner.keil@...
        <mailto:werner.keil@...>> wrote:

        GBP 5 * USD 5 would currently throw a
        CurrencyMismatchException. And so did something like
        GBP 5 + EUR 5, etc.

        Explicit conversion of one currency before you perform those
        operations is required and unless very specific
        implementations doing that under the hood were written
        (unlikely that makes sense for RI, at least there are always
        different conversion rates and fees for such conversions)

        EUR 5 + 5 can be seen more or less like a convenience method.
        Take some of the "Diamond" improvements to Java 7.
        Previously you had to declare a generic type twice, now Java
        will recognize and use the correct type for you.
        Given the most common cases will use the same currency and
        calculations with different currencies at least by the RI
        would normally throw an exception, I would not say the
        MonetaryAmount + MonetaryAmount version should be dropped,
        but the "convenience" or "diamond like" version that assumes
        the only valid currency seems quite appropriate, too.


        On Sat, Jul 13, 2013 at 4:34 PM, Chris Pheby
        <chris@... <mailto:chris@...>> wrote:

            My question was:

            GBP5 *  5  = GBP 25 is clear enough

            But not sure about

            GBP 5 * GBP 5

            or even

            GBP 5 * USD 5

            In what situation would you perform these multiplications?


            EUR 5 + EUR 5 seems clear


            EUR5 + 5 is less clear

            Regards Chris

            *From:*Werner Keil [mailto:werner.keil@...
            *Sent:* 13 July 2013 22:29
            *To:* jcurrency_mail@...
            *Subject:* [JSR-354] Re: Mathematical Operations on

            I remember the latter method was to add a numeric amount
            of the same currency. We do have a restriction or
            guidance, that the currencies of both arguments should be
            the same, otherwise one would never know, which exchange
            rate to explicitely use and where to take it

            So I'd say it makes sense in both cases. For
            multiplication it certainly does even more, are we
            missing a numeric only argument there?



            On Sat, Jul 13, 2013 at 4:15 PM, Chris Pheby
            <chris@... <mailto:chris@...>> wrote:

            On MonetaryAmount, most of the mathematical operations
            are overloaded for both MonetaryAmount and Number as
            parameters. I am not sure this should be the case.

            For example, add and subtract:

            *public* Money add(MonetaryAmount amount);

            *public* Money add(Number amount);

            Adding two MonetaryAccounts makes perfect sense, but
            adding a number to a monetary amt – less clear. Why not
            just convert the number to a MonetaryAmount explicitly.

            For the multiply, divide… and remainder methods, the
            opposite may be true. In this case, it is unclear what
            the meaning of using a MonetaryAmount as an operand is.

            Regards Chris

-- *Anatole Tresch*
    Java Lead Engineer, JSR Spec Lead
    Glärnischweg 10
    CH - 8620 Wetzikon

    /Switzerland, Europe Zurich, GMT+1/
    /Twitter:  @atsticks/
    /Blogs: //
    /Google: atsticks
    Phone   +41-44 334 40 87
    Mobile  +41-76 344 62 79/


Sascha Freitag v/o Dunschtig

[JSR-354] Re: Type of MonetaryAmount

Werner Keil 07/14/2013

[JSR-354] Re: Type of MonetaryAmount

Sascha Freitag 07/28/2013
Please Confirm