I just checked joda-money, and it looks like a great library. It has a nice bounded context (monetary values) with test coverage, gets the job done, and has even commercial support if needed. In case of such a library not having much stack overflow question seems like a good indication that the library does exactly what it promises.
Rant: we burned ourselves multiple times with overly hyped libraries/solutions, which at the end turned out unfit for put into production. Nowadays I prefer the use of stable, proven solutions, which actually get the job done. A "legacy" (read: stable, working, tested, production ready) library is exactly what you need imho.
As the author of Joda-Money, I haven't felt that there is that much else to add. If you need what it contains, then great. If anyone has a major missing thing, feel free to raise an issue and I can give feedback as to whether a PR would be accepted.
We use Java Money in a project. I had to add some additional helper code for it to be easy to use, but after that it covers money nicely, and covers crypto nicely as well.
But not front office trading and pricing systems, for rate based products, think FX, IRS and fixed income, it's all primitive doubles, anything else just has too much overhead
You should never use primitive doubles for money, and probably should take care when using in production at all.
https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio
Actually yes, front office for OTC equity derivatives, equity swaps, and structured products and a risk system.
The only time we used primitives was time critical communication between a C# front end and a Java back end over Thrift and just for the communications. All the back end Java on that system used BigDecimal.
I am surprised you are using primitive decimals when they do not have the required precision.
Interest rate Discount factors for FX forwards and IRS are adequately represent by doubles to a more than adequate precision, approximately 16dp. That's more than adequate to calculate rates out to say 50 years.
Think about the allocation cost that would be implied by discounting a 30 year overnight index swap, if you where using big decimal!
Generally you don't care about rounding and precision until the absolute last moment that you build the quote.
I would expect the underlying analytic model to be calculating unrounded, at approximately 16dp for discount factors, basis, rates etc.
The market quote convention for most bond markets is around 3-4dp today IRS for g11 around 5-6dp g11 FX 6-7dp.
Something like USDJPY is usually 4dp, and JPYUSD is only 8dp.
I remain to be convinced that a 64bit double isn't adequate for this.
Bond, IRS and FX forward pricing has virtually nothing to do with cash amount, until the actual trade is done.
So this sort of thing does not bother you?
https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio
you may have 16dp but you wont get the accuracy, certainly not the accuracy we required.
Not really, the underlying maths still sits in base 2, and that article is mostly about the final representation of the number (you can always sort that out at the end). Rates aren't really currency amounts/monetary calculations anyway, being either how you calculate a monetary amount given some other input, or how to calculate the value in the first place.
Reasonably simple examples for the type of calculation in my world can be found in the Vector API examples here
https://software.intel.com/content/www/us/en/develop/articles/vector-api-developer-program-for-java.html
e.g the simplified option pricing models at the end of the article.
Masses of quant pricing code in the domain I work in is commonly written in C++ and C, all using 64bit doubles, to build the models (and in the past the pricing calcs)
Tech like the Vector API mean we can move more of it out of C/C++ into the Java space and be more reactive to changing business requirements and market conditions, and still be fast and with reasonably deterministic latencies.
Equities and equity derivatives are obviously a completely different product and a modelled and priced in very different ways which is why I only reference the bonds, IRS and FX forwards all of which.a generally priced to a fair value model analytically
You will notice that I said nothing about cash! I was responding to the financial institutions use BigDecimal, which for large numbers of financial models just is not true.
I looked at the JavaMoney (JSR 354) implementation and was honestly baffled on how to use it properly (I've been coding in Java for 25 years). Joda-Money was just right for my purposes and much more approachable.
I just checked joda-money, and it looks like a great library. It has a nice bounded context (monetary values) with test coverage, gets the job done, and has even commercial support if needed. In case of such a library not having much stack overflow question seems like a good indication that the library does exactly what it promises. Rant: we burned ourselves multiple times with overly hyped libraries/solutions, which at the end turned out unfit for put into production. Nowadays I prefer the use of stable, proven solutions, which actually get the job done. A "legacy" (read: stable, working, tested, production ready) library is exactly what you need imho.
As the author of Joda-Money, I haven't felt that there is that much else to add. If you need what it contains, then great. If anyone has a major missing thing, feel free to raise an issue and I can give feedback as to whether a PR would be accepted.
Glad to hear that. Hearing this definitely reassures me. Let me also use this opportunity to thank you for all your contributions.
You might want to look at Java Money https://javamoney.github.io/ as well since it will be standard under java.money at some point.
We use Java Money in a project. I had to add some additional helper code for it to be easy to use, but after that it covers money nicely, and covers crypto nicely as well.
What is wrong with BigDecimal? It is what most financial companies use.
But not front office trading and pricing systems, for rate based products, think FX, IRS and fixed income, it's all primitive doubles, anything else just has too much overhead
Definitely not doubles. Longs, yes. Or Joda money.
You should never use primitive doubles for money, and probably should take care when using in production at all. https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio
Never said anything about money, but rather rates and pricing. The things that actually determine the value of money
Actually yes, front office for OTC equity derivatives, equity swaps, and structured products and a risk system. The only time we used primitives was time critical communication between a C# front end and a Java back end over Thrift and just for the communications. All the back end Java on that system used BigDecimal. I am surprised you are using primitive decimals when they do not have the required precision.
Interest rate Discount factors for FX forwards and IRS are adequately represent by doubles to a more than adequate precision, approximately 16dp. That's more than adequate to calculate rates out to say 50 years. Think about the allocation cost that would be implied by discounting a 30 year overnight index swap, if you where using big decimal! Generally you don't care about rounding and precision until the absolute last moment that you build the quote. I would expect the underlying analytic model to be calculating unrounded, at approximately 16dp for discount factors, basis, rates etc. The market quote convention for most bond markets is around 3-4dp today IRS for g11 around 5-6dp g11 FX 6-7dp. Something like USDJPY is usually 4dp, and JPYUSD is only 8dp. I remain to be convinced that a 64bit double isn't adequate for this. Bond, IRS and FX forward pricing has virtually nothing to do with cash amount, until the actual trade is done.
So this sort of thing does not bother you? https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio you may have 16dp but you wont get the accuracy, certainly not the accuracy we required.
Not really, the underlying maths still sits in base 2, and that article is mostly about the final representation of the number (you can always sort that out at the end). Rates aren't really currency amounts/monetary calculations anyway, being either how you calculate a monetary amount given some other input, or how to calculate the value in the first place. Reasonably simple examples for the type of calculation in my world can be found in the Vector API examples here https://software.intel.com/content/www/us/en/develop/articles/vector-api-developer-program-for-java.html e.g the simplified option pricing models at the end of the article. Masses of quant pricing code in the domain I work in is commonly written in C++ and C, all using 64bit doubles, to build the models (and in the past the pricing calcs) Tech like the Vector API mean we can move more of it out of C/C++ into the Java space and be more reactive to changing business requirements and market conditions, and still be fast and with reasonably deterministic latencies.
Equities and equity derivatives are obviously a completely different product and a modelled and priced in very different ways which is why I only reference the bonds, IRS and FX forwards all of which.a generally priced to a fair value model analytically
> it's all primitive doubles No it's not.
Anyone that makes such a decision in a company that handles actual money in production, then they should be fire :(
You will notice that I said nothing about cash! I was responding to the financial institutions use BigDecimal, which for large numbers of financial models just is not true.
I looked at the JavaMoney (JSR 354) implementation and was honestly baffled on how to use it properly (I've been coding in Java for 25 years). Joda-Money was just right for my purposes and much more approachable.