Description Jim Garrison 2010-09-30 13:05:58 EDT

Build Identifier: BIRT 2.6.1

BubbleDataSetProcessorImpl#getMinimum (and #getMaximum) contains code looking like this:

    Number bnMin = null;
    for ( int i = 0; dsi.hasNext( ); i++ )
    {
        bde = (BubbleEntry) dsi.next( );
        if ( bde != null )
        {
            Object oValue = bde.getValue( );
            if ( NumberUtil.isBigNumber( oValue ) )
            {
                BigNumber bnValue = (BigNumber)oValue;
                bnValue = bnValue.subtract(  (BigNumber) bde.getSizeNumber( ) );
                if ( i == 0 )
                {
                    bnMin = bnValue;
                }
                else
                {
NPE ===>                bnMin = ( (BigNumber) bnMin ).min( bnValue );
                }
            }
            else if ( oValue instanceof BigDecimal )
            {
                BigDecimal bnValue = (BigDecimal)oValue;
                bnValue = bnValue.subtract(  (BigDecimal) bde.getSizeNumber( ) );
                if ( i == 0 )
                {
                    bnMin = bnValue;
                }
                else
                {
NPE ===>                bnMin = ( (BigDecimal) bnMin ).min( bnValue );
                }
            }
            else if ( oValue instanceof java.math.BigDecimal )
            {
                . . . same as above
            }
            else if ( oValue instanceof Number )
            {
                . . . same as above
            }
            else if ( oValue instanceof CDateTime )
            {
                . . . same as above
            }
        }
    }


The problem here is it assumes that the incoming dataset's first entry will always be non-null.  We are seeing a case where the dataset contains

    [null, 969, null, null]

Since the initialization of bnMin is based on the index being zero, an NPE occurs when the index value is 1 since bnMin was not previously set.

I don't know enough about BIRT internals to determine if the incoming dataset
is correct.  This problem started occurring after updating BIRT from 2.5.0 to 2.6.1, with no changes to the report definition or queries.

Reproducible: Sometimes