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:
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
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@...>
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@...
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
GBP 5 * USD 5
In what situation would you perform these multiplications?
EUR 5 + EUR 5 seems clear
EUR5 + 5 is less clear
*From:*Werner Keil [mailto:werner.keil@...
*Sent:* 13 July 2013 22:29
*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.
-- *Anatole Tresch*
Java Lead Engineer, JSR Spec Lead
CH - 8620 Wetzikon
/Switzerland, Europe Zurich, GMT+1/
Phone +41-44 334 40 87
Mobile +41-76 344 62 79/
[JSR-354] Re: Type of MonetaryAmount