[#10451] - NullPointerException at parentElement.getBand().isSplitTypePreventInhibited(isTopLevelCall);

Bug report
Project: Severity:
Component: Reproducibility:
Assigned to:

I am getting a Nullpointer exception when generating report, which used to work in version 6.4 but now fail in 6.5.1.

It fails when there is a tables inside of a band and one cell overflows, so that a page breaks because of this.

2018-02-15 17:36:06.447 ERROR --- [nio-8080-exec-1] n.s.j.engine.fill.JRFillSubreport : Fill 1: exception

java.lang.NullPointerException: null
at net.sf.jasperreports.engine.fill.FillerSubreportParent.isSplitTypePreventInhibited(FillerSubreportParent.java:109)
at net.sf.jasperreports.engine.fill.JRFillBand.isSplitTypePreventInhibited(JRFillBand.java:618)
at net.sf.jasperreports.engine.fill.JRFillBand.isSplitTypePreventInhibited(JRFillBand.java:597)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:2555)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:791)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportStart(JRVerticalFiller.java:252)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:99)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:609)
at net.sf.jasperreports.engine.fill.BaseReportFiller.fill(BaseReportFiller.java:405)
at net.sf.jasperreports.engine.fill.JRFillSubreport.fillSubreport(JRFillSubreport.java:740)
at net.sf.jasperreports.engine.fill.JRSubreportRunnable.run(JRSubreportRunnable.java:59)
at net.sf.jasperreports.engine.fill.AbstractThreadSubreportRunner.run(AbstractThreadSubreportRunner.java:221)

The report is generated and has about 2 pages usually, sometimes up to 10. The reports failing have 2 and 5 pages.

Binary Data closing_detail.jrxml44.3 KB
Binary Data closing_detail_3.jrxml8.9 KB
jasper library
cr_1's picture
Joined: Feb 15 2018 - 9:05am
Last seen: 7 months 1 week ago



It looks like isSplitTypePreventInhibited is called on null. Seems to happen when a table is located in a detail band and the cell of the table is overflowing, that is generating a page break.

  • Reproducibility:Random» Always
  • Severity:Minor» Major


does it also fail if you set:



The same error seems to occur, when

JRPdfExporter exporter = new JRPdfExporter();
exporter.setParameter(JRCalculator.PROPERTY_LEGACY_BAND_EVALUATION_ENABLED, true)

Is set. Is it the right way to activate this configuration?


Fails also using system environment property



To give you a better impression: I appended a PDF file which was successfully created with 6.4.0 but fails with 6.5.1. It seems to only happen when the left sub table overflows and a page break is created.

PDF icon abschluss-15-02-2018_26.pdf31.14 KB

I was able to reduce the jrxml file to a more core variant. See attachment. This file fails for a given input.

Binary Data closing_detail_3.jrxml8.9 KB

The following file is the most simple jrxml file I could produce, where there is still the mentioned error.

Binary Data closing_detail_4.jrxml4.09 KB

No, that's not the correct way to set this configuration since it is not an export parameter.
It has to be active before report filling starts.
To achive this, set this property in the your global jasperreports.properties file (in the root of your classpath).


We have the same issue. Setting 'net.sf.jasperreports.legacy.band.evaluation.enabled=true' in 'jasperreports.properties' doesn't help.

For our tests it works to prevent the NPE in 'FillerSubreportParent' with a null-pointer check: 'return parentElement.getBand() != null && parentElement.getBand().isSplitTypePreventInhibited(isTopLevelCall)'.

But I don't know if that is just a workaround or if it is intended that the band on JRFillSubreport (the 'parentElement') is null. In my tests the 'setBand' method is never called on JRFillSubreport, neither with working reports or with reports that produce the NPE.

With the latter in mind, the method could probably always just return false...


It would be awesome to add a NP check to this function, otherwise we cannot upgrade.


A self contained test case would help with reproducing the problem. E.g. some data to run the report from comment #9.

Adding a null check would be easy, but we need to understand how the problem occurs and decide if the null check is the proper way to fix it.



See appended JRXML file. If you open it in Jaspersoft Studio and try to compile it you will see the mentioned NPE.


Sorry forgot to mention, that the example is using any datasource with at least 6 items. The content of the datasource is not used in the file.

  • Status:New» Confirmed

Thank you for the details, we reproduced the problem.


Great, thank you very much! Can you give me an estimate about when the release is going to happen? The release is great because a bunch of things were sorted out.

If it is weeks, I will patch this file by myself. If its days, then I probably wait for the release.

Thanks for the effort.


We might come up with a fix in a few days/a week, but it will take longer until the next release (6.6) will be out.

  • Priority:Normal» High

Hello, can we get an update on this bug please? Starting to heavily affect my customers.


  • Severity:Major» Critical


I tested the release 6.6 and I still receive the error.
Was this fixed and do you need another example to test ?

net.sf.jasperreports.engine.JRException: java.lang.NullPointerException
at com.jaspersoft.studio.editor.preview.view.control.ReportController.fillReport(ReportController.java:536)
at com.jaspersoft.studio.editor.preview.view.control.ReportController.access$17(ReportController.java:511)
at com.jaspersoft.studio.editor.preview.view.control.ReportController$1.run(ReportController.java:429)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
Caused by: java.lang.NullPointerException
at net.sf.jasperreports.engine.fill.FillerSubreportParent.isSplitTypePreventInhibited(FillerSubreportParent.java:116)
at net.sf.jasperreports.engine.fill.JRFillBand.isSplitTypePreventInhibited(JRFillBand.java:633)
at net.sf.jasperreports.engine.fill.JRFillBand.isSplitTypePreventInhibited(JRFillBand.java:612)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:2589)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:813)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportStart(JRVerticalFiller.java:264)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:110)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:615)
at net.sf.jasperreports.engine.fill.BaseReportFiller.fill(BaseReportFiller.java:413)
at net.sf.jasperreports.engine.fill.JRFillSubreport.fillSubreport(JRFillSubreport.java:814)
at net.sf.jasperreports.engine.fill.JRSubreportRunnable.run(JRSubreportRunnable.java:61)
at net.sf.jasperreports.engine.fill.AbstractThreadSubreportRunner.run(AbstractThreadSubreportRunner.java:221)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)


Well this is embarrassing. It took me a while to get the example done. Can we somehow fork this NPE?


This fork contains the NP check. Documents having the issue before can be generated in this fork:



Hi, it reproduced in my environment too, using 6.6.0 and net.sf.jasperreports.legacy.band.evaluation.enabled=true

But, I found strangely behaviour through some tests.
My production tests generate many reports by changing parameters.
Reported exception and stacktrace occur only when multiple test executed and not every time.
When I execute single test, it never seems to occur.

I can't make sure the cause yet, but FYI.


I can reproduce this as others on version 6.6.0, when can we expect the fix?

  • Resolution:Open» Fixed
  • Status:Confirmed» Resolved
  • Assigned:nobody» lucianc

Fixed at https://github.com/TIBCOSoftware/jasperreports/commit/263d245058d09c6323...

The fix will be part of JasperReports 6.7.0.