*Originally posted @ gratiartis.org on April 6 2007*

As a developer of financial systems, I’m constantly disappointed by how difficult it is to perform precise decimal arithmetic in Java. It’s fairly common knowledge that the use of double is not much use for financial calculations. As a quick example, take a look at the following piece of code.

```
public static void main(String arg[]) {
BigDecimal bd = new BigDecimal("58.99").add(new BigDecimal("0.99"));
System.out.println("BigDecimal result: " + bd);
double d = 58.99 + 0.99;
System.out.println("Double result: " + d);
}
```

You would have thought both results should be the same. However, you end up with:

```
BigDecimal result: 59.98
Double result: 59.980000000000004
```

This is caused by the fact that in Java, operations on double primitive uses floating point arithmetic. The use of floating point arithmetic does make it relatively fast to perform the operations. The approximate nature of them may not matter in all situations, but for financial calculations it can cause all sorts of problems.

As shown above, this issue is resolved by using the BigDecimal. This makes use of precise decimal arithmetic. However, if you’re working on a relatively complex operation, the code bloat can be immense. I’m sure most folks would agree that

`BigDecimal bd = new BigDecimal("58.99").add(new BigDecimal("0.99"));`

is a lot harder to read than

`double d = 58.99 + 0.99;`

COBOL has maintained a lifespan beyond most poeple’s expections largely due to the fact that calculations use precise decimal arithmetic. This has meant that in banks and presumably elsewhere, there continue to be COBOL teams working on various systems. With the recent drive towards encouraging the use of domain-specific languages and the ease with which languages other than Java can be run on the JVM, I have been digging around to find out what people are using in these situations. Unfortunately, so far it looks as though back-end systems continute to use Java and C/C++ with additional (often third patry) precise math libraries. These allow precise math to be used, but as they are not integral to the language, they just cannot be as concise and readable as I would like.

This is where I should probably introduce Groovy. It’s billed as “An agile dynamic language for the Java platform”, with many of the features of other dynamic languages such as Ruby and Python. The syntax is deliberately similar to that of Java, as it is designed to be run on the JVM and interact easily with Java APIs. The reason I bring it up is that as a result of the philosophy of “no surprises” the Groovy Math model assumes exact decimal math as the default for calculations. Groovy literals with decimal points are instantiated as BigDecimal. Although it’s worth noting that if a calculation involves a double, the calculation will proceed using floating point math. You can read more about it at http://groovy.codehaus.org/Groovy+Math but my reason for interest is that for instance, `58.99 + 0.99 == 59.98`

actually evaulates to ‘true’. This means that you can actually start working with exact math on the Java platform in a manner that is easy to read.

I’m not an expert on the internals of these things, so I would be keen to hear other people’s thoughts on the use of Groovy as a domain-specific language for financial calculations on the JVM. Are there better alternatives that I haven’t heard of yet?