RFR: 8336382: Fixes error reporting in loading AWT and fonts

[Phil Race]

On Sat, 13 Jul 2024 00:18:43 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.findFontConfigFile(FontConfiguration.java:180)
>         at java.desktop at 23-internal/sun.awt.FontConf...

There is nothing in this PR that I would accept. It should be withdrawn.

src/java.desktop/share/classes/java/awt/Font.java line 1205:

> 1203:                 throw (FontFormatException)cause;
> 1204:             }
> 1205:             throw new IOException("Problem reading font data.", t);

Revert this. It is done this way as part of a previous security fix to avoid exposing information.
"    8001038: Resourcefully handle resources "

src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 65:

> 63:                                              "java/awt/GraphicsEnvironment");
> 64:         if (graphicsEnvClass == NULL) {
> 65:             // Not finding the class is not necessarily an error.

I can't see how that comment can possibly be true. This change makes no sense.

src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 83:

> 81:                                                      headlessFn);
> 82:         // If an exception occurred, we assume headless mode.
> 83:         if ((*env)->ExceptionCheck(env)) {

I don't like this at all.

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

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20169#pullrequestreview-2178457280
PR Review Comment: https://git.openjdk.org/jdk/pull/20169#discussion_r1678275975
PR Review Comment: https://git.openjdk.org/jdk/pull/20169#discussion_r1678278217
PR Review Comment: https://git.openjdk.org/jdk/pull/20169#discussion_r1678278403