Hi Nicolas, Following up on this — I ran load tests on the new screenxlsx implementation to evaluate memory behavior at scale.
The new implementation is built on Apache POI's streaming extension, SXSSFWorkbook (rather than the standard in-memory XSSFWorkbook). Because it flushes rows beyond a small sliding window to temporary storage, it avoids the heap exhaustion and OOMs traditionally associated with POI. In testing up to 500k rows (and across concurrent sessions), heap consumption remained virtually flat (< 30 MB delta), and 100k rows exported cleanly in ~5 seconds. I have posted the detailed benchmark results, memory profiling metrics, and comparative analysis directly on the ticket: https://issues.apache.org/jira/browse/OFBIZ-13567 Given these results confirm large-volume streaming is well-handled, we can safely proceed with retiring the legacy screenxls implementation. Regards, Mridul Pathak On Fri, Sep 11, 2026 at 3:28 PM Mridul Pathak <[email protected]> wrote: > Hi Nicolas, > > Thanks for providing the context regarding the screenxls implementation. > I'll load test the new POI based implementation and see if it can address > high volumes. If not, it definitely makes sense to keep the original > implementation intact. > > Regards, > Mridul Pathak > > On Fri, Sep 11, 2026 at 2:38 PM nicolas.malin.nereide.fr via dev < > [email protected]> wrote: > >> Hello, >> >> Thanks for your work on this renderer. It's nice. >> >> Just for the screenxls, it was created to support massive export for >> than 100k lines. The reason that it use macro ftl to open continuous >> string stream instead of load a java object like Apache POI did. >> >> By the past, when I used Apache POI to did that, the lib failed with out >> of memory due to huge memory consumption. If you implementation fix that >> it's really good and we can set screenxls as deprecated, otherwise it >> would be good to keep it and add a description on each case to use >> screenxls and screenxlsx >> >> Nicolas >> >> >> Le 08/09/2026 à 15:04, Mridul Pathak a écrit : >> > Hi all, >> > >> > I've opened two PRs adding a new screenxlsx view-handler type that >> produces >> > genuine binary .xlsx workbooks via Apache POI: >> > https://github.com/apache/ofbiz-framework/pull/1899 for the core >> mechanism, >> > andhttps://github.com/apache/ofbiz-plugins/pull/395 wiring it into the >> > example plugin's demo screens alongside a couple of new UI entry points. >> > Both PRs are purely additive and don't touch any existing behavior, >> tracked >> > as OFBIZ-13567. >> > >> > The motivation is that the existing screenxls view-handler type doesn't >> > actually produce a real Excel file: its FreeMarker macros just emit a >> plain >> > HTML table, and it only opens in Excel because Excel is lenient about >> > mismatched file extensions and content types, while tools like >> LibreOffice >> > and Google Sheets are far less forgiving. The new screenxlsx handler >> builds >> > a real OOXML workbook directly from the same widget form/grid data, with >> > typed cells for currency and date fields, and has been verified >> end-to-end >> > against a running instance producing files that open cleanly everywhere. >> > >> > This makes screenxls obsolete. If there are no objections, I'll file a >> > follow-up ticket to remove it once OFBIZ-13567 lands. >> > >> > Reviews and feedback on the PRs are very welcome. >> > >> > Thanks, >> > Mridul Pathak >> > >> >
