Upgrade PDF exporter to OpenPDF 2.x (or publish an alternate module targeting 2.x)

[mafaul]

Summary

Please update the JasperReports PDF exporter to use OpenPDF 2.x (Java 17+), or provide an alternate artifact that targets OpenPDF 2.x alongside the current 1.x line.

Why this is needed

• Ecosystem alignment. Recent versions of Flying Saucer and XDocReport have standardized on OpenPDF 2.x. Projects that also use JasperReports end up with split OpenPDF major versions on the classpath, forcing workarounds (shading/relocation) and increasing build complexity.
• Java 17 readiness. OpenPDF 2.x officially targets modern JDKs (we’re on Java 17), and projects adopting current LTS JDKs expect PDF dependencies to match that baseline.
• Maintenance & fixes. New features and bug/security fixes are landing primarily on the 2.x line. Staying on 1.x increases the risk of drift and missed fixes over time.
• Developer experience. Eliminating the need to relocate com.lowagie.* classes reduces build time, avoids subtle runtime clashes, and simplifies dependency management for users who combine JasperReports with other PDF stacks.

Impact / Compatibility

• Breaking changes: OpenPDF 2.x introduced API and behavioral changes relative to 1.x. A straight swap in existing JasperReports versions may be breaking, so a major or feature release (or an alternate artifact) is the safest route.
• Minimum JDK: OpenPDF 2.x requires Java 17+, so the upgrade (or alt module) should document the supported JDK matrix clearly.

Proposed paths (any would help consumers)

1. Primary: Upgrade jasperreports-pdf to OpenPDF 2.x in the next major JasperReports release.
2. Alternate module: Publish a sibling artifact, e.g. jasperreports-pdf-openpdf2, wired to OpenPDF 2.x, so users can opt in without breaking existing users on 1.x.
3. Maven profile (interim): Provide an officially supported Maven profile that switches the PDF exporter to OpenPDF 2.x (with CI coverage), until (1) or (2) lands.

Acceptance criteria

• A published artifact (or mainline change) that depends on OpenPDF 2.x.
• CI/tests cover core PDF features (fonts/encoding, images, vector graphics, tables, page events, encryption/signing if applicable).
• Clear release notes: min JDK, migration notes, and any known behavior differences vs. the 1.x-backed exporter.

Environment (requester)

• JDK: 17
• Build: Maven
• Other PDF libs in the app: Flying Saucer (OpenPDF 2.x), XDocReport (OpenPDF 2.x)

Workarounds we use today (pain points)

• Shading/relocating OpenPDF 2.x into a private namespace to avoid clashes with JasperReports’ OpenPDF 1.x on the classpath. This works but adds complexity and risk.

Ask

• Is there a roadmap to move to OpenPDF 2.x?
• If a direct upgrade isn’t planned soon, could you consider publishing an alternate 2.x-backed exporter so downstream projects can align with the broader PDF ecosystem without heavy shading?

[teodord]

This recently got a bit more complicated (or not?) with the release of OpenPDF 3.0.0.
It comes with changed package names, to avoid split packages, but requires Java 21.

[teodord]

The release of OpenPDF 3.0.0, with its package name changes, seems to make OpenPDF 2.0 more like a transitional thing, which might not make sense to rely on for too long.

[teodord]

Decided that for now, we are going to upgrade to latest 1.3.43, which would allow users to upgrade up to 2.4.0 without the need for our library to be recompiled against a newer OpenPDF. We have tested all our samples and they work with OpenPDF 2.4.0 even if our library is built against 1.3.43.

We are going to revisit this approach after OpenPDF 3+ gains some more traction.