On Tue, 26 Nov 2024 15:11:58 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 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
