RFR: 8336382: Fixes error reporting in loading AWT and fonts [v4]
Karm Michal Babacek
duke at openjdk.org
Sat Sep 28 23:13:42 UTC 2024
On Sat, 28 Sep 2024 23:03:56 GMT, Karm Michal Babacek <duke at openjdk.org> wrote:
>> 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.findFontConfigF...
>
> 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 thr...
# Font.java and information leakage
@prrace @jerboaa
Would this solution address the concern? Instead of passing on the whole throwable, we just inspect it and if it is this particular one, we pass on the information to the user?
+++ b/src/java.desktop/share/classes/java/awt/Font.java
@@ -971,6 +971,9 @@ public static Font[] createFonts(InputStream fontStream)
}
return createFont0(fontFormat, fontStream, true, tracker);
} catch (InterruptedException e) {
+ if (e.getCause().getMessage().contains("java.home property not set")) {
+ throw new IOException("Problem reading font data. java.home property not set.");
+ }
throw new IOException("Problem reading font data.");
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2381019606
More information about the client-libs-dev
mailing list