Double Versus Money

The Money class is supposed to work entirely with decimal (not floating point) arithmetic, to avoid rounding problems - as described in places like Martin Fowler's Patterns of Enterprise Application Architecture

The reality is short of that ideal:

• Many callers to new Money(String) get their string from a call to Double.toString(double Value)
• There are many callers to Money#amountAsDouble, a method which should not exist.

While we're on the subject of Money, some methods don't make sense (Money#multiply(Money), for example - it should just be Money#multiply(Double) - where the second argument maybe could be changed to BigDecimal or int or something, but not Money), which is making the callers do strange things about what is stored in a Money and what is not.

The Time And Money library is worth considering, if we're refactoring Money anyway.

A cursory look at the Time and Money library leads me to believe we wouldn't have much to gain by switching from the Mifos Money class to theirs. Both classes use BigDecimal for decimal arithmetic. One useful tidbit is that their Currency is simply that built in to Java... perhaps we should be using that core class for currency information as well. -Adam

Also took a cursory look at this library. It uses MIT license, which basically means you can use it for any purpose. Looks reasonably well maintained. It has a few good ideas to be gleaned - e.g. passing in roundingRule as a parameter, using Java Currency as Adam noted, their approach to handling "persistent mapping frameworks". In general, there is much to be gained from using other OS projects, but in this case, the Money.java file is only about 336 lines long, so it seems like something we should just read for ideas, rather than integrating it in at this point. If we do use any ideas from it, we should cite it as a reference in comments. -Sam

Another issue related to the Money class and monetary storage in general is the way that Money gets persisted to the database is a pair of fields (amount and currency). This is awkward and probably would be more natural to have the currency selected at a coarser level (per-account or per-branch, say). This will all make more sense once we do Multicurrency for real - right now all those currency fields don't really do anything.

There are some links at Interesting Tech Questions to various currency rounding articles (a somewhat random collection, and probably worth moving the relevant bits to this page, but someplace to start).

Comment from Beth- I have put some links at Money Requirement Links that I found interesting in terms of handling money in financial applications in Java: