"on Java's inability to natively perform decimal arithmetic"
The temptation is to use float and double, but these are approximating types and
cannot be used in monetary computation (rounding errors...).
I first experimented with a Lawson-specific Decimal class (I still have the
interface if you'd like) but ultimately settled on BigDecimal.

A related item was the Cobol "compute" verb which has no analog in Java.
One example is the Cobol computation of ecomomic order quantity:
  COMPUTE EOQ = ( (2 * ANNUAL-QTY * ORDER-COST) / (CARRY-PCT * UNIT-COST) ) **
.5.

In Java, the solution is rather circumspect but still coherent.
  BigDecimal annualQty, orderCost, carryPct, unitCost; //assume these have been
initialized correctly
  BigDecimal numerator = new BigDecimal( "2.0" );
  numerator = numerator.multiply( annualQty );
  numerator = numerator.multiply( orderCost );
  BigDecimal denominator = carryPct.multiply( unitCost );
  double eoq =
    Math.sqrt( numerator.doubleValue( ) / denominator.doubleValue( ) );

This example is contrived in that we are already approximating the result with
the .sqrt() function, but our Cobol-migrating to Java programmers face similar
examples each day.
With some native support for a decimal type (such as offered in C#), the
application developer's need for precise decimal arithmetic might be realized.
While BigDecimal offers an expressive set of functions, the developer must be
constantly vigilant of its immutability, sensitivity to doubles, etc.
This really slows the adoption of Java by the mainstream applications developer.