A Report Unit Works in JRS 7.9 Dev but Failed in JRS 7.5 Prod Server

Problem

User has reported that they "have a report that runs well in the Jaspersoft Studio and the DEV report server, but it failed in the PROD report server. The Prod report server version is 7.5.0 while the dev server is 7.9.0".

Analysis

Jumping into conclusion, one might think the most plausible explanation of the problem is a report compatibility issue - perhaps the report template contains a design feature that only works in the new version of the JasperReports engine (JRL). 

Upon further review of the error message, however, the issue is not related to JRS/JRL versions used in user's production. Rather, it is caused by user's report data:

net.sf.jasperreports.engine.fill.JRExpressionEvalException: Error evaluating expression for source text:

$V{GroupGrandTotal}.equals(0.0) ? "0.00%" : new BigDecimal($V{GroupItemTotal}.floatValue()*100/($V{GroupGrandTotal} .floatValue())).setScale(2, BigDecimal.ROUND_HALF_UP)+"%"

............

Caused by: java.lang.NumberFormatException: Infinite or NaN

This error indicates the GroupGrandTotal report variable contains zero which cannot be used as a denominator in a division operation.

User had attempted to handle this situation by this ternary expression

$V{GroupGrandTotal}.equals(0.0) ?... : ...

However, the BigDecimal.equals() method takes scale into consideration thus it only works when the group tally is exactly 0.0, not 0, or 0.00 nor 0.000, etc.

Solution

User should use the BigDecimal.compareTo() method instead to handle BigDecimal zero value evaluation irrespective of the scale:

($V{GroupGrandTotal}==null||BigDecimal.ZERO.compareTo($V{GroupGrandTotal})==0)?... : ...

After making the change, the user is able to run this report successfully in all environments.

Note

Since the comparable interface requires a class instance to operate, users should ensure the BigDecimal field contains non null value. The normal way of using a constant literal in the ternary expression will not provide the safety net to handle the null situation when compareTo() method is used. Therefore users need to cover the null condition in the expression to be "NullPointerException" safe.

Reference

• java.math.BigDecimal
• BigDecimal compareTo() Function in Java
• Interface Comparable

--------------------------------------------------------------------------

20240425-TTC-2260030