JDK 23 javadoc quietly embeds ~4MB of DejaVu fonts into Maven package docs

Two tiny packages, eight megabytes

A developer writing on dev.to under the handle hrgdavor ran into a puzzling figure while releasing two small Java libraries to Maven Central. The repository's usage tracking showed roughly 8MB attributable to the pair — artifacts that should have weighed kilobytes. The cause turned out not to be the code at all, but the generated API documentation.

According to the post, JDK 23 changed the behavior of the javadoc tool so that it now includes a default set of DejaVu web fonts, about 4MB in total, inside the documentation it produces. Two packages, each carrying its own copy of those fonts in the javadoc output, neatly explain the unexpected 8MB.

The flag that turns it off

The JDK provides an escape hatch: javadoc accepts a --no-fonts option that suppresses the font embedding. The post notes that the maven-javadoc-plugin can relay this option to the underlying javadoc executable, and demonstrates the approach with plugin version 3.11.3 using an additionalOptions configuration entry that appends --no-fonts to the javadoc invocation.

The post also describes a disableNoFonts plugin setting and a maven.javadoc.disableNoFonts property that can be set from the command line, though its prose and its code sample are not fully consistent about the exact values to use. The dependable route shown is the additionalOptions block, which hands the flag directly to javadoc.

A version compatibility trap

There is a catch that makes this more than a one-line fix. As the post points out, --no-fonts only exists from JDK 23 onward. Feed the option to javadoc running on JDK 21 or earlier and the tool rejects it as an unrecognized option, breaking the build.

That means projects compiling across several JDK lines — a CI matrix, or contributors on whatever JDK they have installed locally — cannot simply hard-code the flag everywhere. They either need Maven profiles that apply the option only on JDK 23 and newer, or a build pinned to a single JDK version.

Why it matters

The change is easy to miss precisely because nothing fails. Builds succeed, the generated pages look the same, and the only visible symptom is artifact size creeping up by about 4MB per javadoc bundle. For one library that is an annoyance; multiplied across the many projects publishing javadoc artifacts to Maven Central, it amounts to a large volume of redundant, byte-identical font files flowing through the repository, its mirrors, and every downstream consumer's downloads and caches.

For maintainers of small libraries, where a javadoc jar can end up orders of magnitude larger than the code it documents, it distorts the footprint the project actually ships. And because the fix is tied to a specific JDK version, the configuration a team writes today is coupled to whichever JDK their build runs on — something worth checking before the next release goes out.