On Sat, 28 Sep 2024 23:03:56 GMT, Karm Michal Babacek <[email protected]> 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 [email protected]/java.awt.Font.createFont0(Font.java:1205) >> at [email protected]/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.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 [email protected]/java.awt.Font.createFont0(Font.java:1205) > at [email protected]/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
