Skip to main content
Last updated April 12, 2015 22:39, by Anatole
Feedicon  
=<img align="right" src="http://asset-1.java.net/attachments/images/project/javamoney.png?20121214.f926c51"/> <br/>JSR 354 - Aspects regarding Precision<br/><br/><br/> Basically it is required to support very large numbers and a very large number of decimal places. There is quite some debate on how this can be realized efficiently. Candidates identified are * <code>BigDecimal</code> * single <code>long</code> * two <code>long</code>s (pounds & fraction) * new <code>Decimal</code> class (probably wrapping two longs) * <code>double</code> should be ruled out as inaccurate * <code>Number</code> should be ruled out as being abstract and non-precise It was decided that the JSR must be able to support multiple implementations with corresponding interoperability rules. In concrete a Money class, that will encapsulate BigDecimal and a FastMoney class that includes one long is included in the JSR's reference implementation. Additionally different precision types were identified: * '''internal precision''' defines the precision used for performing arithmetical operations. By default a <code>MonetaryAmount</code> will always represented/rounded to this internal precision internally. This allows to separate concrete rounding requirements from the types numeric representation. * When monetary amounts with different precision are used for a caclulation: ** then the higher of both precisions is used for the result. This is also the case if the system's internal precision is less. ** If the higher of both precisions is less than the internal precision, the result has the internal precision. * '''external precision''' is the precision applied, when a <code>MonetaryAmount</code> is externalized, e.g. by calling one of the <code>int toInteger(), double toDoubple(), float toFloat() </code> etc. methods, or by calling <code>T asType(Class)</code>. Hereby the precision basically should be the same as the internal precision, but the representation of the externalized value may require to reduce the precision. In case of the <code>toInteger()</code> method this is quite obvious. * '''formatting precision''' this is the precision (or rounding) applied, when a monetary amount should be formatted for print out or display. All these must be clearly separated, especially external and formatting precision are not part of the monetary amount's value type. Nevertheless the '''internal precision''' also must be serialized somehow, since different VMs may operate with different internal precisions. Therefore it is important that the precisoin information is also available on the target VM, so different precisions can be managed..
 
 
Close
loading
Please Confirm
Close