RFR: 8336382: Fixes error reporting in loading AWT and fonts [v10]
Phil Race
prr at openjdk.org
Tue Jan 28 23:26:58 UTC 2025
On Tue, 26 Nov 2024 15:11:58 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 incrementally with one additional commit since the last revision:
>
> Amended error message, doesn't clear exception
So this is much better than what was there in the beginning.
FindClass failing - for a key API class - is probably a fatal error one way or another.
Although in all (?) other cases, we try to return to Java and let the VM throw a Java-level error.
Note that OnLoad is not the only code path that calls AWTIsHeadless, and there will be
Java code to return to in the other case.
However I think that the OnLoad will always be reached first, so maybe it is OK to do the current fix.
Either way, things aren't going to work.
Generally the calls to check and clear exceptions when looking up code are there
to keep 'tools' happy. If these classes aren't found something is badly wrong.
meaning it should NEVER EVER happen.
Failing to find java/lang/String for example hardly seems like something it is worth trying to recover from ..
In your case it seems like it does some times happen for GraphicsEnvironment which still worries me.
I don't want to make this fix a precedent for assuming that it is normal for classes to be missing.
So consider it a truly exceptional case.
-------------
Marked as reviewed by prr (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20169#pullrequestreview-2579630865
More information about the client-libs-dev
mailing list