RFR: 8336382: Fix error reporting in loading AWT [v10]

[Magnus Ihse Bursie]

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

See https://bugs.openjdk.org/browse/JDK-8349099

@Karm I was wondering why this did not show up on GHA (it's probably not executed there). But I noticed when researching this that your last merge from mainline was in September. Even if there are no "physical" merge conflicts that git can detect, there are likely to be "logical" conflicts like this, where a library was removed that your test depended on.

So for a long running PR like this, when it is ready to be checked in, you need to merge in main and verify that the fix (and the tests) still works, and nothing else breaks. If there are no "physical" conflicts you do not need to push the merge to the PR on github, since that might invalidate approvals, but you need to test it locally. 

As for how long "long running" is, I don't know. A week without merge is likely okay, 3 months is not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2627351962