[JAVAMONEY-25] Multi MonetaryAmount and CurrencyUnit Values Created: 02/Feb/13  Updated: 11/Mar/14  Resolved: 11/Mar/14

Status: Closed
Project: javamoney
Component/s: Impl: RI
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: atsticks Assignee: atsticks
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: MonetaryAmount, compount_amount, multi-currency, multi-value


Define a compound multi-valued monetary amount that consists of several amounts:

  • of the same currency, but with different semantics, e.g. for use cases in insurance calculations
  • of different currencies, e.g. for easily switching between currencies supported in web shop
  • a mix of the above.

A compound value has the following properties:

  • it is immutable.
  • it does not offer arithemtics
  • it provides access to all its containing{{MonetaryAmount}} instances:
    • Map<String,MonetaryAmount> getAll()
    • Enumeration<String> getKeys();
    • MonetaryAmount getMonetaryAmount(String key)
    • boolean isMonetaryAmountDefined(String key)
  • It allows access to all different currencies contained:
    • Enumeration<CurrencyUnit> getContainedCurrencies()
  • it provides a CompoundMonetaryAmountFactory for creating compound values.
  • Since a compound amount is defined to be immutable, it can only be extended/adapted as follows:
    • CompoundMonetaryAmount add(String key, MonetaryAmount amount);
    • CompoundMonetaryAmount remove(String... key);
    • CompoundMonetaryAmountBuilder toBuilder() // and using the builder to create a new instance

Comment by keilw [ 02/Feb/13 ]

Sorry, but this seems a little to specific for most users.
On that I can only agree with Stephen about the 80% of users. It is certainly valid, but shouldn't go into "core", probably more towards one of the EE-related modules or simply an extension.

Comment by chrispheby [ 05/Feb/13 ]

Is another use case an e-'wallet' concept for the above?

Comment by atsticks [ 05/Feb/13 ]

Currently only a CompoundItem and CompoundItemBuilder are defined in convert as interfaces. The effective value types are implemented within the RI only as of now. It can be useful to move these interfaces into the extensions module.
Basically one of the most important use cases are pension calculations, where several input parameters are required and also the result of a pension calculation are multiple amounts, e.g. death capital, total capital, buy in option, risk investment strategy amounts etc.

Comment by keilw [ 05/Feb/13 ]

Both CompoundItem and CompoundItemBuilder are generic in convert, so they seem more like "specialized Collection API" elements than part of "Conversion API", I agree they might go to "ext", which doesn't prevent certain implementations from using those interfaces. Whether or not that'll be the RI and for which target platform, we shall see.

Comment by atsticks [ 11/Mar/14 ]

This Feature has not shown to be useful as part of API/RI. May be something can be added to lib, but also here there is no real Advantage to just using a map of <x, MonetaryAmount>.

Generated at Thu Mar 30 00:18:54 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.