RFR: 8336382: Fixes error reporting in loading AWT and fonts [v4]
Karm Michal Babacek
duke at openjdk.org
Sat Sep 28 23:03:56 UTC 2024
> If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as:
>
> Fatal error reported via JNI: Could not allocate library name
>
> Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time.
>
> Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g.
>
> * https://github.com/oracle/graal/issues/9138
> * https://github.com/oracle/graal/issues/8475
> * https://github.com/oracle/graal/issues/9300
> * https://github.com/quarkusio/quarkus/issues/31596
> * https://github.com/graalvm/mandrel/issues/292
> * https://github.com/Karm/mandrel-integration-tests/issues/262
>
> This commit fixes the error reporting in the AWTIsHeadless.
>
> Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g.
>
> /tmp/JAVA_HOME/
> /tmp/JAVA_HOME/conf
> /tmp/JAVA_HOME/conf/fonts
> /tmp/JAVA_HOME/lib
>
> The exception is somewhat cryptic for users again, merely stating:
>
> Exception in thread "main" java.io.IOException: Problem reading font data.
> at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205)
> at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076)
> at imageio.Main.loadFonts(Main.java:139
>
> Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing:
>
> Exception in thread "main" java.io.IOException: Problem reading font data.
> at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206)
> at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076)
> at imageio.Main.loadFonts(Main.java:139)
> at imageio.Main.paintRectangles(Main.java:97)
> at imageio.Main.main(Main.java:195)
> at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)
> Caused by: java.lang.Error: java.home property not set
> at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
> at java.desktop at 23-internal/sun.awt.FontConf...
Karm Michal Babacek has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
- Merge branch 'master' of github.com:openjdk/jdk into awt-load-messages-fonts_backup
- Display "Problem reading font data. java.home property not set." when java.homenot set and AWT cannot try to lookup fonts
- Treats missing class as a fatal error
- Reverts changes to java/awt/Font.java
- Fixes error reporting in loading AWT and fonts
If there is problem with finding and calling e.g. java/awt/GraphicsEnvironment
in AWTIsHeadless, the env' Exception remains set and it not cleared.
Later, that manifests as:
Fatal error reported via JNI: Could not allocate library name
Which is misleading. The code path is perhaps rare in normal JDK usage,
but it has been complicating our users' bug reports in the GraalVM/native-image
ecosystem for quite some time.
Instead of failing later with some clear message that indicates that the
user has incorrectly configured JNI, it bails out very soon with a message
that seems as if a jstring could not have been allocated. It sends users
on wild goose chases, e.g.
https://github.com/oracle/graal/issues/9138
https://github.com/oracle/graal/issues/8475
https://github.com/oracle/graal/issues/9300
https://github.com/quarkusio/quarkus/issues/31596
https://github.com/graalvm/mandrel/issues/292
https://github.com/Karm/mandrel-integration-tests/issues/262
This commit fixes the error reporting in the AWTIsHeadless.
Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME,
yet some parts of AWT code look for it to search fonts. In such case, an
empty directory structure is enough to accommodate it, e.g.
/tmp/JAVA_HOME/
/tmp/JAVA_HOME/conf
/tmp/JAVA_HOME/conf/fonts
/tmp/JAVA_HOME/lib
The exception is somewhat cryptic for users again, merely stating:
Exception in thread "main" java.io.IOException: Problem reading font data.
at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205)
at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076)
at imageio.Main.loadFonts(Main.java:139
Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing:
Exception in thread "main" java.io.IOException: Problem reading font data.
at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206)
at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076)
at imageio.Main.loadFonts(Main.java:139)
at imageio.Main.paintRectangles(Main.java:97)
at imageio.Main.main(Main.java:195)
at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)
Caused by: java.lang.Error: java.home property not set
at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
at java.desktop at 23-internal/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20169/files
- new: https://git.openjdk.org/jdk/pull/20169/files/4e33725a..8b203e7c
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20169&range=03
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20169&range=02-03
Stats: 256790 lines in 3090 files changed: 209022 ins; 30625 del; 17143 mod
Patch: https://git.openjdk.org/jdk/pull/20169.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20169/head:pull/20169
PR: https://git.openjdk.org/jdk/pull/20169
More information about the client-libs-dev
mailing list