I am currently developing an ERP (Enterprise Resource Planning) system and need to make decisions regarding the type of data to use for handling calculations and other numerical values within the application.
I know that Java offers several options for handling decimal numbers, such as BigDecimal and Double. I understand that each has its own advantages and disadvantages, but I want to ensure that I choose the most appropriate one to maintain precision and efficiency in my system.
Here are some specific contexts where I need to apply calculations:
- Billing and Payments: handle prices, taxes, discounts, etc.
- Payroll and Accounting:
- Inventory Management: Including unit prices and product costs.
I am inclined to use BigDecimal for financial operations due to the precision it offers, but I am concerned about the impact on performance. On the other hand, Double might be more efficient in terms of speed but could introduce rounding errors.
What recommendations do you have for handling these cases in an ERP? In which situations would it be preferable to use BigDecimal and when Double? Are there any patterns or best practices I should follow?
2
For all kinds of money-related calculations, it would be careless not to use BigDecimal. Please use BigDecimal for all your calculations.
What happens if you don’t do it? The inaccurate precision of Double can lead to simply wrong results when performing any kind of mathematical operation. Wrong results can cost your company money, credibility, and time to correct wrong calculations.
Performance will most likely not be an issue. Only tackle performance issues when they arise and don’t pre-optimize for a problem that does not exist.
2
BigDecimal: Use for all financial calculations (billing, payments, payroll, accounting) where precision is critical.
Reasons:
- financial operations are legally bound to be accurate to the smallest unit (like cents), and BigDecimal provides that precision.
- Accounting standards demand high precision, and rounding errors could lead to compliance issues.
Double: Use for non-financial calculations, large-scale data processing, and performance-critical sections where slight precision loss is acceptable.
- The key here is to use BigDecimal when the numbers directly affect financial outcomes and Double when working with large datasets where performance is critical, and slight precision loss is tolerable.
1
Avoid floating-point for money
Floating-point technology trades away accuracy for speed of execution.
In Java, the primitive types float and double are floating point types. So are their wrapper classes, Float and Double. So never use these where accuracy matters. That means never for money.
Use either BigDecimal or whole integers
Instead, fractional money amounts must be handled in either of these approaches:
- Use
BigDecimalobjects. This type is much slower than floating-point, but accurate. The syntax is clumsier than numeric literals, of course. But on the up-side, besides accuracy, you get handy methods such as Banker’s Rounding. - Move the decimal point by multiplication to get a whole number. For example, to track USD to the penny, multiply by 100 to get cents as whole integer values (
long). To track USD to the tenth of a cent, multiply by a thousand to represent mills.
Table of types for fractional money
floating-pointint & float |
BigDecimal |
Whole integer | |
|---|---|---|---|
| Example: | 1.23d | new BigDecimal( "1.23" ) |
long cents = new Double( 1.23d * 100 ).longValue() ; |
| Notes: | Never use for money | Accurately represents fractional amounts. | Requires that you multiply fractional inputs, and divide to get fractional outputs. |
| Pros: | Fast execution. Convenient use as literals. | Handy methods, such as Banker’s Rounding. | Fast execution. Simple type, with direct matching types in database. |
| Cons: | Inaccurate. | Slow. Clumsy syntax. | May be confusing to naïve programmer & user. (Be sure to label clearly and consistently such as cents or mills.) |
2