Handle missing font system error on Java 21

[liff]

In Java 21 the RuntimeException from sun.awt.FontConfiguration is not wrapped in an InternalError anymore and appears directly as a RuntimeException when constructing a TextLayout.

So, when ignoreMissingFontSystem is set also allow a RuntimeException to indicate a missing font system.

A demonstration of the difference (without POI and assuming JDK >=17 and Docker are available):

1. Create Test.java with content:

   public class Test {
       public static void main(String args[]) {
           var frc = new java.awt.font.FontRenderContext(null, true, true);
           var str = new java.text.AttributedString(String.valueOf('W'));
           var layout = new java.awt.font.TextLayout(str.getIterator(), frc);
   
           System.out.println(layout.getAdvance());
       }
   }

2. Compile
3. Run on Java 17:

   docker run -it --rm -v $(pwd)/Test.class:/Test.class amazoncorretto:17-alpine java Test

4. Run on Java 21:

   docker run -it --rm -v $(pwd)/Test.class:/Test.class amazoncorretto:21-alpine java Test

On Java 17, you’ll see:

Exception in thread "main" java.lang.InternalError: java.lang.reflect.InvocationTargetException
…
Caused by: java.lang.RuntimeException: Fontconfig head is null, check your fonts or fonts configuration

On Java 21, the result is:

Exception in thread "main" java.lang.RuntimeException: Fontconfig head is null, check your fonts or fonts configuration
…

[pjfanning]

@centic9 - is ok to treat all non-fatal exceptions in this try block as meaning we are likely to be missing fonts? So far, trying to specify specific exception types is just running into issues with different JDK setups. We have an ExceptionUtil that can be used to check if a Throwable is fatal or not.

[centic9]

I think here it will be fine as we only handle it when the system property is set to true and only some JDK code for computing the text-length is called at that point, so the chance for other unexpected exceptions is low.

[centic9]

Unfortunately the check on ExceptionUtil.isFatal() is now causing failures in cases where we would like graceful handling, e.g. UnsatisfiedLinkError here usually indicates that font-libraries are not installed, but it will now be thrown even if ignoreMissingFontSystem is set.

The change actually reverted the behavior for the three types of exception that were handled before..

We will need to rework this so that the three types of exception which were caught before are still seen as "font libraries missing".