0006284: Use of double instead of BigDecimal, double is very inprecise

Description

There are a few cases in Openbravo source code where a double type is used. A double is far more in-precise than a BigDecimal. Always a BigDecimal should be used.
See for example this code in the ReportGeneralLedger class:
        double amount = 0.0;
        for (int i=0;data2!=null && i<data2.length;i++){
          if (data2[i].factAcctId.equals(data[0].factAcctId)) {
            if (log4j.isDebugEnabled()) log4j.debug("break i:"+i);
            break;
          };
          // if (data2[i].id.equals(data[0].id))
          if ((data2[i].partner.equals(data[0].partner) && (!(strcBpartnerId.equals("")&&(strAll.equals("")))))||(strcBpartnerId.equals("")&&(strAll.equals(""))))
            amount += Double.valueOf(data2[i].total).doubleValue();
        }

Here a BigDecimal should be used.

Search for the use of double in the source tree and repair the incorrect uses.

Tags

No tags attached.

Attached Files

Relationships [ Relation Graph ] [ Dependency Graph ]

duplicate of	defect	0004512	2.50	closed	vmromanos	Float Point Errors
depends on	backport	0006477		closed	vmromanos	Use of double instead of BigDecimal, double is very inprecise

Notes
(0011117) rafaroda (viewer) 2008-12-10 10:28	Please take a look at the related issue and if it is duplicated, close one of them.

(0011952) vmromanos (viewer) 2009-01-07 15:41	This issue is duplicating 0004512. Please close this one because I am currently working on 0004512

Issue History
Date Modified	Username	Field	Change
2008-11-30 23:10	mtaal	New Issue
2008-11-30 23:10	mtaal	Assigned To	=> rafaroda
2008-11-30 23:10	mtaal	sf_bug_id	0 => 2367178
2008-11-30 23:10	mtaal	OBNetwork customer	=> No
2008-11-30 23:10	mtaal	Regression testing	=> No
2008-12-01 13:00	shuehner	Issue Monitored: shuehner
2008-12-03 19:03	pjuvara	Priority	normal => high
2008-12-09 12:52	pheenan	Assigned To	rafaroda => Dowid
2008-12-10 10:27	rafaroda	Relationship added	related to 0004512
2008-12-10 10:28	rafaroda	Note Added: 0011117
2008-12-11 09:40	Dowid	Status	new => scheduled
2008-12-11 09:40	Dowid	fix_in_branch	=> trunk
2009-01-07 15:41	vmromanos	Note Added: 0011952
2009-01-07 15:43	mtaal	Relationship replaced	duplicate of 0004512
2009-01-07 15:43	mtaal	Status	scheduled => closed
2009-01-07 15:43	mtaal	Duplicate ID	0 => 4512
2009-01-07 15:43	mtaal	Resolution	open => duplicate