3 ms·

Java has JSR 354 for money [1]. There is also a reference implementation [2]. So there is official support for money in Java. [1] https://jcp.org/en/jsr/detail

Java has JSR 354 for money [1]. There is also a reference implementation [2]. So there is official support for money in Java. [1] https://jcp.org/en/jsr/detail?id=354 https://jcp.org/en/jsr/detail?id=354 [2] https://javamoney.github.io/ https://javamoney.github.io/

owlstuffing 2y ago
Would be cool to hook this up as a manifold unit[1]. This way you could write code like: Money ask = 2.1M USD; What I don't see with the Java JSR is how exchange rate services are integrated (if at all?). In the best of worlds, as with manifold's units I could write. Money deposit = 300 USD + 500 EUR; Where internally the deposit automatically maintains the amounts separately and uses exchange rates only for spot display/calc, transfer, etc. 1. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#unit-expressions https://github.com/manifold-systems/manifold/tree/master/man...
- willcipriano 2y ago
  I'd like types for all the currencies. USD rent = 2000 EUR salary = 6000.53 USD disposableIncome = salary - rent Then: disposableIncome.toDecimal() disposableIncome.toInteger() disposableIncome.toString() USD interest = disposableIncome.compoundInterest(startDate, endDate, apy) USD tip = billTotal.tip(percentage) USD and EUR would inherit from Money Not sure how to implement it, might be a JVM magic thing.
  - owlstuffing 2y ago
    What you want is Money, currency is a _unit_ type of a Money quantity, just as meter is a unit type of Length. Money cost = 25M USD; cost += 12M EUR; display(cost.to(EUR));
    - wtetzner 2y ago
      I don't think this makes sense? You need to specify an exchange rate somewhere. > just as meter is a unit type of Length The difference is that length units are fixed, but exchange rates are constantly changing.
      - owlstuffing 2y ago
        > You need to specify an exchange rate somewhere. Right. As I mentioned earlier exchange rate services would need to be integrated into the API. Also, exchange rate services would not be needed until a conversion is necessary. For instance, when adding money of different currencies internally the Money type maintains currencies separately, subtotals for USD, EUR, etc. are managed. If at a later time the sum of Money should be displayed, deposited, etc. as a single currency, only then is an exchange service involved.
- wtetzner 2y ago
  > Money ask = 2.1M USD; Feels like it should be Money<USD> ask = 2.1M USD; Then methods like .plus() wouldn't even be defined for incompatible currencies. Of course that doesn't work for .equals(), so you'd still have to fall back to exceptions in that case.
  - owlstuffing 2y ago
    Generally, the idea is that there is no incompatibility between units. Money is a bit exotic given its abstract nature wrt units / exchange rates. For instance, physical dimensions store values as SI units, regardless of supplied unit, but retain the supplied unit type as a display hint. Here, the Length dimension illustrates working with amounts of any unit. Length orbit = 250 mi; Length moon = 238000 km; Length landing = moon + orbit; display(landing); // prints 148,136.344 mi display(landing.to(km)); // prints 238,402.336 km // where display(landing.to(mi) == landing.to(km)); // prints true // perhaps a better example Rate rate = 1.41 km/s; Time duration = 76 hours; Length distance = rate * duration; // make your own unit constants RateUnit kps = km/s; rate = 1.41 kps; You can play with the manifold-science[1] project, it implements the complete SI physical dimensions and many derived dimensions along with comprehensive operator overloading[2] support etc. to make working with and reading code using quantities more productive in Java. 1. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-science https://github.com/manifold-systems/manifold/tree/master/man... 2. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#operator-overloading https://github.com/manifold-systems/manifold/tree/master/man...
- oftenwrong 2y ago
  The JSR 354 API can provide access to exchange rate services via the ExchangeRateProvider interface. The reference implementation (Moneta) includes a few implementations of ExchangeRateProviders that connect to online services to look up exchange rates.
jeroenhd 2y ago
It will never not be funny to me how Java language designs have such a hatred for operator overloading yet will happily accept .multiply(2).add(something) as a substitute.
flykespice 2y ago
Except Kotlin is a multiplatform language now thanks to Jetbrains efforts (kmp project), it's not anymore intertwined with JVM. Using Java library will limit your program only to jvm platform. Using a kotlin library like this one (given it's written in pure kotlin and doesn't uses any jvm platforms specifics) will allow you to build it to whatever target kmp supports (macosx, ios, android, js, mingw...)
- jsiepkes 2y ago
  > to build it to whatever target kmp supports (macosx, ios, android, js, mingw...) Plenty of languages (also Java with Graal, TeaVM, J2CL, etc.) can also target these platforms. But as with all these languages targeting these platforms (including Kotlin) you are going to have to call platform specific API if you want to do anything useful. There are also platforms specific limitations which means certain stuff which you can do in the language doesn't work on those platforms.
- eriksencosta 2y ago
  Not yet to Android (in the case of the library). Need to revamp some internal things.

owlstuffing 2y ago

Would be cool to hook this up as a manifold unit[1]. This way you could write code like: Money ask = 2.1M USD; What I don't see with the Java JSR is how exchange rate services are integrated (if at all?). In the best of worlds, as with manifold's units I could write. Money deposit = 300 USD + 500 EUR; Where internally the deposit automatically maintains the amounts separately and uses exchange rates only for spot display/calc, transfer, etc. 1. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#unit-expressions https://github.com/manifold-systems/manifold/tree/master/man...

willcipriano 2y ago
I'd like types for all the currencies. USD rent = 2000 EUR salary = 6000.53 USD disposableIncome = salary - rent Then: disposableIncome.toDecimal() disposableIncome.toInteger() disposableIncome.toString() USD interest = disposableIncome.compoundInterest(startDate, endDate, apy) USD tip = billTotal.tip(percentage) USD and EUR would inherit from Money Not sure how to implement it, might be a JVM magic thing.
- owlstuffing 2y ago
  What you want is Money, currency is a _unit_ type of a Money quantity, just as meter is a unit type of Length. Money cost = 25M USD; cost += 12M EUR; display(cost.to(EUR));
  - wtetzner 2y ago
    I don't think this makes sense? You need to specify an exchange rate somewhere. > just as meter is a unit type of Length The difference is that length units are fixed, but exchange rates are constantly changing.
    - owlstuffing 2y ago
      > You need to specify an exchange rate somewhere. Right. As I mentioned earlier exchange rate services would need to be integrated into the API. Also, exchange rate services would not be needed until a conversion is necessary. For instance, when adding money of different currencies internally the Money type maintains currencies separately, subtotals for USD, EUR, etc. are managed. If at a later time the sum of Money should be displayed, deposited, etc. as a single currency, only then is an exchange service involved.
wtetzner 2y ago
> Money ask = 2.1M USD; Feels like it should be Money<USD> ask = 2.1M USD; Then methods like .plus() wouldn't even be defined for incompatible currencies. Of course that doesn't work for .equals(), so you'd still have to fall back to exceptions in that case.
- owlstuffing 2y ago
  Generally, the idea is that there is no incompatibility between units. Money is a bit exotic given its abstract nature wrt units / exchange rates. For instance, physical dimensions store values as SI units, regardless of supplied unit, but retain the supplied unit type as a display hint. Here, the Length dimension illustrates working with amounts of any unit. Length orbit = 250 mi; Length moon = 238000 km; Length landing = moon + orbit; display(landing); // prints 148,136.344 mi display(landing.to(km)); // prints 238,402.336 km // where display(landing.to(mi) == landing.to(km)); // prints true // perhaps a better example Rate rate = 1.41 km/s; Time duration = 76 hours; Length distance = rate * duration; // make your own unit constants RateUnit kps = km/s; rate = 1.41 kps; You can play with the manifold-science[1] project, it implements the complete SI physical dimensions and many derived dimensions along with comprehensive operator overloading[2] support etc. to make working with and reading code using quantities more productive in Java. 1. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-science https://github.com/manifold-systems/manifold/tree/master/man... 2. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#operator-overloading https://github.com/manifold-systems/manifold/tree/master/man...
oftenwrong 2y ago
The JSR 354 API can provide access to exchange rate services via the ExchangeRateProvider interface. The reference implementation (Moneta) includes a few implementations of ExchangeRateProviders that connect to online services to look up exchange rates.

jeroenhd 2y ago

It will never not be funny to me how Java language designs have such a hatred for operator overloading yet will happily accept .multiply(2).add(something) as a substitute.

flykespice 2y ago

Except Kotlin is a multiplatform language now thanks to Jetbrains efforts (kmp project), it's not anymore intertwined with JVM. Using Java library will limit your program only to jvm platform. Using a kotlin library like this one (given it's written in pure kotlin and doesn't uses any jvm platforms specifics) will allow you to build it to whatever target kmp supports (macosx, ios, android, js, mingw...)

jsiepkes 2y ago
> to build it to whatever target kmp supports (macosx, ios, android, js, mingw...) Plenty of languages (also Java with Graal, TeaVM, J2CL, etc.) can also target these platforms. But as with all these languages targeting these platforms (including Kotlin) you are going to have to call platform specific API if you want to do anything useful. There are also platforms specific limitations which means certain stuff which you can do in the language doesn't work on those platforms.
eriksencosta 2y ago
Not yet to Android (in the case of the library). Need to revamp some internal things.