Retrieve resource bytes from map as URLStreamHandler can be shared

[jperedadnr]

This PR fixes #2291.

When this approach is used:

URL resource1 = getClass().getResource("some.name");
URL resource2 = new URL(resource1, "other.name");

the first resource is registered during build time, and the URL is created via Resources::createURL (on runtime), where a new URLStreamHandler() is created based on its resourceBytes.

However, for the second resource, the URLStreamHandler from the context (the first resource) is used, according to the URL constructor.

If that is the case, the resourceBytes can't be taken from the first resource, and the resources map has to be used to retrieve such bytes, if such resource2 exists and was correctly registered during built time.

In the test case added to the issue, the Bogus.class resource is not found, so a FNFE is thrown, and the test succeeds.

Another use case of such approach can be found in the JavaFX FXMLLoader class, when an FXML file loads another FXML resource via fx:include, see issue.

[johanvos]

Tested this locally, and it fixes the issue indeed.

[jovanstevanovic]

It looks like we are dealing with the same issue. The only difference is that my changes are part of bigger resource refactoring. Take a look at changes in this PR #3315. If you have any suggestions let me know.

[thomaswue]

@olpaw or @christianwimmer can you please look at this?

[jperedadnr]

@jovanstevanovic Building GraalVM from head (so #3315 is included), works (at least related to the resources issues #2291 and gluonhq/substrate#291), but only on Mac and Linux. Windows fails.

I've run these two tests:

• JavaFX/FXML code. On Windows it produces a NullPointerException:

[INFO] [SUB]  Caused by: java.lang.NullPointerException: Location is required.
[INFO] [SUB]   at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:3310)
[INFO] [SUB]   at javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:3274)

• Java/ XML code, on Windows it fails with:

[INFO] [SUB] java.net.MalformedURLException: no protocol: Child.xml
[INFO] [SUB]   at java.net.URL.<init>(URL.java:645)
[INFO] [SUB]   at java.net.URL.<init>(URL.java:541)
[INFO] [SUB]   at hello.HelloWorld.main(HelloWorld.java:42)

[jperedadnr]

I've also tested some dev builds for Java 11 on Windows:

• up until https://github.com/graalvm/graalvm-ce-dev-builds/releases/tag/21.2.0-dev-20210612_0244 "works", but still has Nonexistent relative classpath resource appears to exist in native image #2291, as expected. A regular FXML sample works fine.

• starting with https://github.com/graalvm/graalvm-ce-dev-builds/releases/tag/21.2.0-dev-20210615_0052 fails with same errors reported for both App test and FXML app with fx:include, but also a new error shows up for the regular FXML sample:

[INFO] [SUB] java.util.MissingResourceException: Can't find bundle for base name hellofx.hello, locale en_US
[INFO] [SUB]   at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2055)

[olpaw]

@jovanstevanovic the findings from @jperedadnr indicate that the new resource implementation does not work as expected on Windows. Please fix this on master and also on the soon-to-created 21.2.0-branch. Resource support has to work properly for all our supported platforms.

[olpaw]

@jperedadnr thanks for your testing #3336 (comment) #3336 (comment)

Now that @jovanstevanovic s new resource support is on master the changes this PR provides are obsolete and the PR should be closed. Makes sense?

Sure, no problem, you can close this PR.
However, and if it helps: since this PR fixes it for Windows, if it is useful for #3315, feel free to use all or parts of it.

Thanks. I will create a new issue and make it refer to this PR for guidance.

Created #3496

[jperedadnr]

Sure, no problem, you can close this PR.

However, and if it helps: since this PR fixes it for Windows, if it is useful for #3315, feel free to use all or parts of it.

[olpaw]

Sure, no problem, you can close this PR.

However, and if it helps: since this PR fixes it for Windows, if it is useful for #3315, feel free to use all or parts of it.

Thanks. I will create a new issue and make it refer to this PR for guidance.

[gradinac]

Hey @jperedadnr! Thank you for reporting the issue and testing this out! It turned out to be a problem with the way we pass file paths to resource inclusion matchers. I've opened #3498 to address this and I've tested out gluonhq/substrate#291 (comment):

• When child.xml isn't manually added to the config, we get an exception
• When child.xml is manually added to the config, the test seems to work

The reason we need to add the resource manually is because the native-image-agent can't see this resource as accessed as the access happens through URL manipulation.

I've noticed that there were a couple of other Gluon samples, specifically https://github.com/gluonhq/gluon-samples/tree/master/HelloFXML, however, these seem to require a custom GraalVM build on Windows to test. Could you please try out the fix and see if it works, or is there another reproducer that I could run locally? I've tried running it without a custom GraalVM build but I was hitting linker errors due to missing symbols

[jperedadnr]

I could try to apply the patch from #3498 to do a custom build and then run the tests again on Windows. I'll report back.

[jperedadnr]

I've tested successfully this patch, the three tests reported that were failing now pass.

[gradinac]

Thank you very much for verifying this! :)
I'll merge this PR to master and to the 21.2 release branch