Alternatives & Other Ecosystems

Twenty-odd tools reduce to five families, which is what matters when you choose. Within a family the trade-offs are similar, and the families differ in what they ask of the developer.

The table lists every library surveyed. "Version" is the latest release on the registry of the tool’s ecosystem (listed in References), and the official pages are listed there too. For licences, "permissive" means MIT, BSD or Apache-2.0, and "copyleft" means GPL or LGPL, whose obligations depend on whether you link, modify or redistribute.

Reading the table by questions:

A common source of confusion is that OpenPDF and iText share a past. The old iText 1 and 2 line (package com.lowagie.text) was licensed under the MPL and LGPL. From iText 5 onward the code moved to the AGPL, and iText 7 and later is a rewrite with a different API (kernel, layout and so on); iText 5 itself is end of life. Books and tutorials written for the com.lowagie API describe the old licence and the old classes, not what you get from Maven Central today under the name iText: iText 9 is AGPLv3 or commercial. OpenPDF is the LGPL and MPL community fork of the old API, still maintained, and its 3.0 line renames the packages from com.lowagie to org.openpdf, so migrating from 2.x or earlier to 3.x is a package rename plus a version bump. JasperReports 7 uses a separate OpenPDF-based fork for its PDF back end. Which of them you pick is therefore less about the code you can copy from the internet and more about the licence you can accept; the API mapping from the old classes to iText 9 is on iText Architecture & Modules.

PDFBox is the Apache-licensed library for creating, reading, merging and filling PDFs. It does not lay out text for you: you set a font, a position and a string, and wrapping and pagination are your code. That is the right level when the document is small and fixed, such as a label, a cover sheet or a stamp, and PDFBox is also the library that the rest of this section uses for signing and for form filling. Maven coordinates (first use on this page):

This example was compiled and run against PDFBox 3.0.8 on Java 21 language level, and produced a one-page PDF. Since PDFBox 3 the standard 14 fonts are created from Standard14Fonts.FontName; the old PDType1Font.HELVETICA_BOLD constants are gone. A standard font has no embedding and only a Latin character set, so use PDType0Font.load with a TrueType file for anything else. Official documentation: PDFBox getting started and the 3.0 migration guide.

OpenHTMLtoPDF renders XHTML and CSS to a PDF through PDFBox. Input must be well-formed XML (use an HTML cleaner such as jsoup to convert from HTML5), and the CSS support is a CSS 2.1 subset with some extensions, not a browser. The project publishes under the group io.github.openhtmltopdf. Maven coordinates (first use on this page):

This example was compiled and run against OpenHTMLtoPDF 1.1.97 together with PDFBox 3.0.8, producing a one-page PDF. For conformance, the builder has usePdfAConformance and usePdfUaAccessibility options; they are listed in the project README but were not exercised here. Official documentation: OpenHTMLtoPDF on GitHub and its wiki.

Gotenberg is a Docker image that exposes Chromium and LibreOffice conversions as HTTP routes. From Java you call it with any HTTP client; the pattern is to keep the PDF engine out of the application’s JVM and container, so a browser crash or a memory spike does not take the service down. The request below converts an HTML file with curl; the image tag follows the major version.

This request follows the route reference and was not run on the machine used to write this page, because no container runtime was available; verify the field names against the version of the image you deploy. Gotenberg needs an index.html file in the multipart request, and referenced assets are sent as extra files in the same request. Official documentation: Convert HTML with Chromium.

Both drive Chromium from code. page.pdf() prints the page using the print stylesheet and works only in headless Chromium, so the same HTML you review in a browser is what is printed. The example is Node because that is the reference API; Playwright also has Java, Python and .NET bindings with the same method.

This snippet was not run on the machine used to write this page; the tagged option is documented for Playwright 1.42 and later. Treat Chromium as a heavy dependency: a pool of reused browsers, a timeout per page and a memory limit per container are not optional in production. Official documentation: Playwright page.pdf() and Puppeteer page.pdf().

The tools below are not callable from a Java service without an extra process, but they are what a team in that ecosystem will use, and knowing them helps when you share a document pipeline.

Apache POI (Excel, Word and PowerPoint) is covered by a separate issue, #262, and is not part of this section.

Start from the constraint, not from the library:

The simplest check is the one the rest of this section uses: build the same Bookshelf Billing invoice with two candidates and compare the output, the code and the dependencies. A day of that costs less than a wrong choice.