1. Maintaining fractions to the proper number of decimal places when doing the math.
2. Maintaining the proper association between each monetary amount and its currency, as the amount passes through the system
3. Determining what exchange rates to use when converting amounts between currencies.
4. Properly localizing a monetary amount/currency combination when converting it to a string for display purposes.
5. Properly parsing an entered string back into a monetary amount with respect to the local formatting customs.
6. Persisting the monetary amount/currency combination as a single entity/atom.

There was no ready-made solution that covers all of these bases that we could find. The java.util.Currency type can be used to represent the currency code (en.wikipedia.org/wiki/ISO_4217, e.g. USD, EUR), but it does not represent any actual amount, nor the exchange rates. (One thing it does know is the number of decimal places associated with each currency.)One Money utility class we found (www.diasparsoftware.com/toolkit/apidocs/com/diasparsoftware/java/util/Money.html) was written by J.B.Rainsberger, the author of “JUnit Recipes” so it’s presumably quality code, but it is USD-specific. Our research also pointed us to Martin Fowler’s “Quantity” pattern. It combines an amount with a unit as described in his Analysis Patterns book (and online at www.martinfowler.com/ap2/quantity.html), and the main example of how to use it is for monetary amounts. He also has a Convertor pattern and a Money Bag pattern (book only). We would have referenced that if we had to start completely from scratch; however, …

We settled on using TimeAndMoney because, at least, it has the first two points above solidly covered. We had to add our own support for localization, though. Also, although there was an existing side project for Hibernate support (plus one patch), it didn’t take advantage of the User Type construct in Hibernate (for Money), so we had implement that as well. These are the patches mentioned above. My team is anxious for feedback.

BTW, we haven’t tackled the exchange rate conversions yet. I don’t ever expect to find a prepackaged solution for that, since that’s mostly a matter of subscribing to a service that provides the current rates and then just performing the arithmetic. Of course, the application will somehow have to determine when and how to lock in the rates over time, but that’s a business rules problem, not a money representation problem.