It seems there is currently no way to avoid this dependency on some fonts being available.

We can review this in the future to see if there is a way to handle this more gracefully, maybe by catching and logging the exception with a fallback column width.

Patches highly welcome!

what is the security implications of having no fonts?
would it be compromised if we (try to) register a default font in the case we don't find any fonts?

We actually tried to solve this via #66230, but the implementation seems to be flawed, as the JVM throws an "InternalError", which is not part of the "Exception" class-hierarchy. 

A small further fix is necessary to adjust for this and make it work properly.

Should be solved now via r1906218

I added r1907308 due to https://github.com/apache/poi/pull/425 - but looks like it might be causing issues itself

Hello,
We are currently working with Apache POI version 5.2.3 and are encountering an issue that appears to be similar to the one reported by Alex for version 4.1.2. Our application is built on OpenJDK slim (11th version) and does not have any installed fonts.

In the source code, sheet is created with method:
SXSSFWorkbook.createSheet(sheetName)

Stack trace:
java.lang.InternalError: java.lang.reflect.InvocationTargetException
	at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74)
	at java.desktop/java.awt.Font.getFont2D(Font.java:497)
	at java.desktop/java.awt.Font.canDisplayUpTo(Font.java:2250)
	at java.desktop/java.awt.font.TextLayout.singleFont(TextLayout.java:469)
	at java.desktop/java.awt.font.TextLayout.<init>(TextLayout.java:530)
	at org.apache.poi.ss.util.SheetUtil.getDefaultCharWidth(SheetUtil.java:301)
	at org.apache.poi.xssf.streaming.AutoSizeColumnTracker.<init>(AutoSizeColumnTracker.java:117)
	at org.apache.poi.xssf.streaming.SXSSFSheet.<init>(SXSSFSheet.java:95)
	at org.apache.poi.xssf.streaming.SXSSFWorkbook.createAndRegisterSXSSFSheet(SXSSFWorkbook.java:726)
	at org.apache.poi.xssf.streaming.SXSSFWorkbook.createSheet(SXSSFWorkbook.java:745)
Caused by: java.lang.NullPointerException
	at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
	at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225)
	at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107)
	at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719)
	at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:379)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:324)
	at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
	at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)


Is there any workaround for this case, or which fonts should be specified to install in the Dockerfile to resolve the issue?

Have you tried disabling the AutoSizeColumnTracker ?

There are unreleased code changes that should fix this. I'm not sure if we are ready to do a release though.

(In reply to PJ Fanning from comment #7)
> Have you tried disabling the AutoSizeColumnTracker ?

By disabling do you mean usage of method SXSSFSheet.untrackAllColumnsForAutoSizing()?

To be honest, until we do a 5.2.4 release, you might be best creating your own POI jars that start with the code in POI 5.2.3 but that cherry pick some SXSSF commits form this year.

It might be worth looking at https://github.com/quarkiverse/quarkus-poi who worked around this issue. Have a look at their Docker image. Its setup may help you to set up your own Docker image.

Okay, I've seen some commits related to catching exceptions in the SXSSFSheet constructor (UnsatisfiedLinkError). 
Thank you, I will probably create my own JAR for now as you suggested, and I'm looking forward to the 5.2.4 release.

Likely fixed on trunk and in the next release, thus resolving again.

Posting my workaround from Github:

I had the same problem. I went through the stacktrace. In the SheetUtil.java getDefaultCharWidth is called. In case of an internal error as reported by OP you can handle that error when the system property "org.apache.poi.ss.ignoreMissingFontSystem" is set to true. It will return a default char width then instead of rethrowing the error.

So you either set this property to true in your environment or you might add a configuration to your spring application as following:

@configuration
public class FontConfiguration {

@PostConstruct
public void setProperty() {
    System.setProperty("org.apache.poi.ss.ignoreMissingFontSystem", "true");
}
}