Question

I am using JasperReports with Spring MVC for reporting in my application.
Basically I first design reports in iReport 4.1.1 and then put the resulting .jasper file in my class path via jasper-view.xml

When the request comes, the controller puts the required parameters from Session to Parameter Map and generates report.

The scenario is there are about 15 subreports in my main report.
Out of all these reports, only reports which match the criteria (passed as parameters) are printed (controlled via “Print When” option of the Band)

And my question is: if my report is not to be printed does it gets executed (i.e. the query inside it)?
or is it simply skipped?

My reason for asking this question is that report generation takes quite a long time (around 2s, which is too long for my application according to me).

Thanks.

Answer 1

If you look at the source code for ‘Jasper Reports’, the logic says that the ‘printWhenExpression’ is evaluated first and then the report element is filled, if it is to be printed.

Below is a method called ‘fillNoData‘ from JRVerticalFiller.java (version 4.0), which says so:

private void fillNoData() throws JRException
    {
        if (log.isDebugEnabled() && !noData.isEmpty())
        {
            log.debug("Fill " + fillerId + ": noData");
        }

        noData.evaluatePrintWhenExpression(JRExpression.EVALUATION_DEFAULT);

        if (noData.isToPrint())
        {
            while (noData.getBreakHeight() > pageHeight - bottomMargin - offsetY)
            {
                addPage(false);
            }

            noData.evaluate(JRExpression.EVALUATION_DEFAULT);

            JRPrintBand printBand = noData.fill(pageHeight - bottomMargin - offsetY);

            if (noData.willOverflow() && noData.isSplitPrevented() && isSubreport())
            {
                resolveGroupBoundElements(JRExpression.EVALUATION_DEFAULT, false);
                resolveColumnBoundElements(JRExpression.EVALUATION_DEFAULT);
                resolvePageBoundElements(JRExpression.EVALUATION_DEFAULT);
                scriptlet.callBeforePageInit();
                calculator.initializeVariables(ResetTypeEnum.PAGE, IncrementTypeEnum.PAGE);
                scriptlet.callAfterPageInit();

                addPage(false);

                printBand = noData.refill(pageHeight - bottomMargin - offsetY);
            }

            fillBand(printBand);
            offsetY += printBand.getHeight();

            while (noData.willOverflow())
            {
                resolveGroupBoundElements(JRExpression.EVALUATION_DEFAULT, false);
                resolveColumnBoundElements(JRExpression.EVALUATION_DEFAULT);
                resolvePageBoundElements(JRExpression.EVALUATION_DEFAULT);
                scriptlet.callBeforePageInit();
                calculator.initializeVariables(ResetTypeEnum.PAGE, IncrementTypeEnum.PAGE);
                scriptlet.callAfterPageInit();

                addPage(false);

                printBand = noData.fill(pageHeight - bottomMargin - offsetY);

                fillBand(printBand);
                offsetY += printBand.getHeight();
            }

            resolveBandBoundElements(noData, JRExpression.EVALUATION_DEFAULT);
        }
    }

What you need to look into, is how the usage of subreports affects performance and memory usage. It looks like you have too many subreports embedded in the main report. Here’s something from this JasperForge link:

Is there performance concerns with Subreports?

The answer to this depends on your system, data source and your report
design. A few points to note on Subreports:

• Each subreport execution may spawn a new thread (see below).
• As the subreport executes more objects will be created in Heap Memory.

On the subject of threads. Support for Java continuations has been
added as an alternative to threads. This was done using the Jakarta
Commons Javaflow library. The JasperReports property:
net.sf.jasperreports.subreport.runner.factory can be used with the
following two settings:

• net.sf.jasperreports.engine.fill.JRContinuationSubreportRunnerFactory
• net.sf.jasperreports.engine.fill.JRThreadSubreportRunnerFactory

By default
net.sf.jasperreports.engine.fill.JRThreadSubreportRunnerFactory is
used, however if
net.sf.jasperreports.engine.fill.JRContinuationSubreportRunnerFactory
is set, then a Javaflow approach will be used to fill the reports
rather than threads. If this option is choosen, then the Jakarta
Commons Javaflow jar must be included in the application classpath.
This jar can be found in the lib directory of the JasperReport reports
project distribution package. The jasperreports-javaflow.properties
file illustrates how this property could be set in a actual
implementation. Other alternatives for processing different queries in
the same report are usage of the List element and Sub Datasets.