-3

Now we have an existing Java application dealing with finance issues. But it was implemented several years ago using "double" type instead of "BigDecimal". I can show the difference between those two types, but for the samples we got, those small errors caused by "double" may not lead to a different result when we use "BigDecimal". So how can I convince my boss that it worth spending some time on rewriting this application? Or is there a law or something official that states it is kind of standard to use BigDecial in financial industry? Thnaks.

  • Any coding 'laws' will eventually be broken. – K.Niemczyk Sep 23 '15 at 17:10
  • 3
    possible duplicate of [Representing Monetary Values in Java](http://stackoverflow.com/questions/285680/representing-monetary-values-in-java) – Michael Petch Sep 23 '15 at 17:10
  • why your boss wants to re-create this app just because of some variable's data-type problem? This is bug caused by double, does not make sense to re-invent the wheel. – Sindhoo Oad Sep 23 '15 at 17:12
  • why are you convinced to use it? jot down those arguments and present them. – NG. Sep 23 '15 at 17:13
  • not sure if you can have an answer for this, since it depends on the perspective of each person.... the pros and the cons, costs of rewriting , time and so on – jpganz18 Sep 23 '15 at 17:13
  • 4
    Sorry, this question is destined to be controversial and will probably get closed as it is primarily opinion-based. Also the answer to "always use `BigDecimal` or `long` or Joda-Money" is correct, but rewriting a functional application might __not__ be. Anyway, if your tests prove that your solution works in all business-required cases, you're fine. If you can't prove that, you'll have to convince your boss by showing him the potential threats. There's no law or anything official that makes this task easy. – Petr Janeček Sep 23 '15 at 17:14
  • Oliver, you should probably contact the Financial Computation Police. – async Sep 23 '15 at 17:22

2 Answers2

2

The conversion to BigDecimal is done in a fixed time, possibly incremental when you have a really large code base or you want to migrate/test per module.

Accountancy may well have a stand: either pro, or contra ("I can keep an account of cent differences").

Data errors caused by double will happen irregularly and at least do not present the firm well to the outside. Bills for 0.01 cents is just one thing.

Repairs will cost more time and cannot as well be affirmed (places of rounding might not all be found at the correct spot).

Package deals: If your country uses a decimal comma, the software the decimal point, do all together. The same for right alignment of numbers, thousand separators.

Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
1

This question has been answered many times.

Apart for the benefits of BigDecimal here is an exemplary issue that double/float face (from here):

double h1 = 100.266d;  
double h2 = 100.0d;  

//Outputs 0.26600000000000534 instead of 0.266
System.out.println(h1-h2);  

In case h1 and h2 has to do with money then you have a problem :)

Mike Argyriou
  • 1,250
  • 2
  • 18
  • 30