-
Bug
-
Resolution: Fixed
-
P4
-
24
-
None
-
b09
-
generic
-
generic
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.
* [native compiled image crashes when java.awt.Desktop.getDesktop is used oracle/graal#9138](https://github.com/oracle/graal/issues/9138)
* [macOS Native Image libawt fails to load due to JNU_NewStringPlatform failure oracle/graal#8475](https://github.com/oracle/graal/issues/8475)
* [native-image-agent ceased to work as expected with AWT/JNI oracle/graal#9300](https://github.com/oracle/graal/issues/9300)
* [ImageIO AWT Quarkus IT test fails with GraalVM 23.0.0-dev build after AWT change quarkusio/quarkus#31596](https://github.com/quarkusio/quarkus/issues/31596)
* [Quarkus Tika IT fails with Mandrel 21.2 and 20.3 while passing with GraalVM CE 21.2 graalvm/mandrel#292](https://github.com/graalvm/mandrel/issues/292)
* [[24.1] imageio AWT tests fail with JDK 23 ea Karm/mandrel-integration-tests#262](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@22.0.1/java.awt.Font.createFont0(Font.java:1205)
at java.desktop@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@23-internal/java.awt.Font.createFont0(Font.java:1206)
at java.desktop@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@23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)
Caused by: java.lang.Error: java.home property not set
at java.desktop@23-internal/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
at java.desktop@23-internal/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
```
```
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.
* [native compiled image crashes when java.awt.Desktop.getDesktop is used oracle/graal#9138](https://github.com/oracle/graal/issues/9138)
* [macOS Native Image libawt fails to load due to JNU_NewStringPlatform failure oracle/graal#8475](https://github.com/oracle/graal/issues/8475)
* [native-image-agent ceased to work as expected with AWT/JNI oracle/graal#9300](https://github.com/oracle/graal/issues/9300)
* [ImageIO AWT Quarkus IT test fails with GraalVM 23.0.0-dev build after AWT change quarkusio/quarkus#31596](https://github.com/quarkusio/quarkus/issues/31596)
* [Quarkus Tika IT fails with Mandrel 21.2 and 20.3 while passing with GraalVM CE 21.2 graalvm/mandrel#292](https://github.com/graalvm/mandrel/issues/292)
* [[24.1] imageio AWT tests fail with JDK 23 ea Karm/mandrel-integration-tests#262](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@22.0.1/java.awt.Font.createFont0(Font.java:1205)
at java.desktop@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@23-internal/java.awt.Font.createFont0(Font.java:1206)
at java.desktop@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@23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)
Caused by: java.lang.Error: java.home property not set
at java.desktop@23-internal/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180)
at java.desktop@23-internal/sun.awt.FontConfiguration.<init>(FontConfiguration.java:97)
```
- causes
-
JDK-8349099 java/awt/Headless/HeadlessMalfunctionTest.java fails on CI with Compilation error
-
- Resolved
-
- links to
-
Commit(master) openjdk/jdk/1858dc14
-
Review(master) openjdk/jdk/20169