Report causing `OutOfMemoryError` when run on certain records

[grantfitzsimmons]

Describe the bug

While developing a new Cryptogam report in Specify, RBGE has run into this issue:

I am trying to add a new field to a label template and I keep getting a java error (java.lang.OutOfMemoryError: Java heap space).

I have updated the query and the fields included in the report to include the new field, and I have copied various other fields in the template in the hope that one of the syntaxes will work – however I just keep hitting the error.

To Reproduce
Steps to reproduce the behavior:

1. Use a copy of the herb_rbge database made after 2025-07-14
2. Run the "Cryptogam Packet" report on the Collection Object with a catalog number of 00000662 (/specify/view/collectionobject/662)
3. See the out of memory error

Below is the query and report file:
Label Template (Updated).json
Cryptogam Packet.jrxml.zip

After removing the following expression in the "Report Memory Investigation" label, the error does not happen with Collection Object 00000662:

($F{1,10,2,3.geography.country} == null ? "" : $F{1,10,2,3.geography.country} + "; ") +
			        ($F{1,10,2,3.geography.subcountry} == null ? "" : $F{1,10,2,3.geography.subcountry} + "; ") +
			        ($F{1,10,2,3.geography.subsubcountry} == null ? "" : $F{1,10,2,3.geography.subsubcountry} + "; ") +
			        ($F{1,10,2,3.geography.subsubsubcountry} == null ? "" : $F{1,10,2,3.geography.subsubsubcountry} + "; ") +
			        ($F{1,10.collectingevent.verbatimLocality} == null ? "" : "" + $F{1,10.collectingevent.verbatimLocality})

When run again with a large set of records, the out of memory issue returns.

Expected behavior
It should not give an out of memory error when running the query.

Reported By
Robyn at Royal Botanic Gardens Edinburgh

Specify 7 System Information - 2025-08-08T13_48_49.853Z.txt

Additional context

mysql> select co.collectionobjectid, co.catalognumber, count(prep.collectionobjectid) as prep_count from collectionobject co left join preparation prep on prep.collectionobjectid=co.collectionobjectid group by co.collectionobjectid order by prep_count desc limit 10;
+--------------------+---------------+------------+
| collectionobjectid | catalognumber | prep_count |
+--------------------+---------------+------------+
|             174817 | 00174817      |         13 |
|             704687 | 00704687      |         11 |
|             214659 | 00214659      |         11 |
|             531830 | 00531830      |         11 |
|            1711966 | 01711966      |         11 |
|             290466 | 00290466      |         10 |
|             188083 | 00188083      |          9 |
|             730260 | 00730260      |          9 |
|             605800 | 00605800      |          9 |
|             290080 | 00290080      |          9 |
+--------------------+---------------+------------+
10 rows in set (6.31 sec)

The second and fourth COs in particular causes a crash all by themselves:

• 704687 (CatalogNumber: 00704687)
• 531830 (CatalogNumber: 00531830)

[grantfitzsimmons]

From @melton-jason:

The underlying problem was due to some records containing text fields with a lot of text. Specifically, the bounds of the respective elements on the report were small relative to the amount of text needed to be displayed, and the report elements were configured to overflow any text which was not able to be displayed to the next page (which would also be constrained to the same report element size/bounds and overflow rules).
With a sufficiently long value in a text field within a small enough report element bounds set to overflow, a single record can take up multiple pages alone as it tries to show all text for the field.

Because the report is set up to query on un-aggregated Preparation records from a CollectionObject base, the aforementioned problem is exacerbated (i.e., repeated) for each Preparation associated with a CollectionObject (or record associated with CollectionObject) with a text field containing a lot of text.

Theoretically, any sufficiently long text could cause this problem on their report. The possible fields on the report that could cause this problem are:
CollectionObject -> description (1.collectionobject.description)
CollectionObject -> remarks (1.collectionobject.remarks)
CollectionObject -> collectingEvent -> remarks (1,10.collectingevent.remarks)
(Possibly, though less likely to cause problems as it is not repeated for each Preparation) CollectionObject -> preparations -> remarks (1,63-preparations.preparation.remarks)
Most (if not all) text## fields

In my testing, the two text fields which most frequently caused the problem due to length are CollectionObject -> description and CollectionObject -> collectingEvent -> remarks .

To alleviate the issue, I currently recommend the following solution:

For report elements that would show potentially long text fields, (in Jaspersoft Studio 6.21.3) ensure the "Properties -> Appearance -> Print When -> Detail Overflows" property is set to False (unchecked).
Whenever a new page is needed because some data/text is to be "overflown" to the next page, The Print When Detail Overflows behavior dictates whether to print the text in the element again on the new page.
While I have not confirmed the hypothesis, I think this causes some problems if the property is true for elements that themselves cause the overflow: When the text content overflows, Jaspersoft might be trying to restart the contents of the text on the next page (which would again cause an overflow, which would try to restart the contents of the text field, and so on: hence the eventual Out of Memory Error).
With the property set to false, Jaspersoft will not repeat the text contents (that have already been shown) on overflown pages.

In the JRXML, if you have a textField like the following:

You can remove the isPrintWhenDetailOverflows="true" or change it to isPrintWhenDetailOverflows="false".

Attached is a copy of the Cyrptogram Packet report with the above changes made to the report elements that display the CollectionObject -> description and CollectionObject -> collectingEvent -> remarks.

If that solution is insufficient, here is another:
For report elements that would show potentially long text fields, change the "Properties -> Text Field -> Text Adjust" of the report to "Scale Font" or "Cut Text". Both of these Text Adjust properties ensure that the text will not overflow to the next page (ensuring you have exactly one page per Preparation).
"Scale Font " will adjust the size of the font for the text to the largest possible amount such that the text will fit within the report element.
"Cut Text" will cut off the text at exactly the dimensions of the report element, and will not allow any stretching or overflow.

Both of these Text Adjust Properties can be combined with the "Properties -> Appearance -> Size" properties (Width, Height, and Stretch Type), which control how much space the actual report element takes up on the report.