GraalVM's native-image substitute for `ClassLoader.getResource` normalizes resources' names while original doesn't

[zakkak]

Describe the issue
GraalVM's native-image substitute for ClassLoader.getResource normalizes resources' names while the original does not.

Running

        URL url = cl.getResource("META-INF/");
        URL url2 = cl.getResource("META-INF/./");
        System.out.println("url = " + url);
        System.out.println("url2 = " + url2);

in JVM results in:

url = jar:file:/home/zakkak/code/tmp/issue-reproducers/target/reproducer-1.0-SNAPSHOT.jar!/META-INF/
url2 = null

while in native-image it results in:

url = resource:META-INF
url2 = resource:META-INF

I would expect it to return:

url = resource:META-INF/
url2 = null

instead.

cc @jovanstevanovic @vjovanov as it relates to #3597

Steps to reproduce the issue

cd /tmp
git clone --branch resources-with-trailing-slash https://github.com/zakkak/issue-reproducers reproducers
cd reproducers
mvn package
export JAVA_HOME=/opt/jvms/graalvm-ce-java11-22.0.0.2
$JAVA_HOME/bin/java \
  -jar target/reproducer-1.0-SNAPSHOT.jar
$JAVA_HOME/bin/native-image \
  -jar target/reproducer-1.0-SNAPSHOT.jar
./reproducer-1.0-SNAPSHOT

Describe GraalVM and your environment:

• GraalVM version: 9b25754
• JDK major version: 11
• OS: Fedora 35
• Architecture: AMD64

[adinn]

I'm not clear what solution you are expecting here. On the JVM the notion of a jar URL that identifies a resource in a jar on the classpath makes sense. In the context of a native image where there is no classpath, no jars and no loading of resources from a jar it doesn't really make any sense.

This is one of the areas where static and dynamic Java programs are necessarily going to have variant behaviour. Graal could go to great lengths to try to emulate JVM behaviour in an attempt to make programs work exactly the same however they are deployed. However, that may well turn out to be a dead end as indeed it will be in this case.

Imagine Graal hands you back a jar URL as per the JVM. What are you going to do with it other than use it to load the resource (i.e. beyond what you would do with the alternative URL Graal currently returns). If you try to decompose it, analyze its structure or use it to build/compare to other URLs that is only going to get you into deeper trouble.

What is really needed here is not some pretend version of jar URLs that strives to retain continuity but rather a clear and coherent specification of what the various resource APIs do differently on Graal that the implementation can stick to and programmers can rely on.

[zakkak]

I'm not clear what solution you are expecting here. On the JVM the notion of a jar URL that identifies a resource in a jar on the classpath makes sense. In the context of a native image where there is no classpath, no jars and no loading of resources from a jar it doesn't really make any sense.

You are right. What I expect is for native-image to retain the trailing slash in url1 and fail to get a matching resource for "META-INF/./". So IMO the expected output would be:

url = resource:META-INF/
url2 = null

I updated the description to include that as well :)

[Karm]

Could this be wrapped in the same bag? quarkusio/quarkus#22403 (comment)

[jovanstevanovic]

The thing is that Java makes a difference between accessing a resource when the app starts with java -jar ... and java -cp ... <main class>. In the first case, ClassLoader.getResource will make a canonical form out of the resource name. In the second case, it won't, as you show in this example.

In your case, your PR fixes the problem, but it very certainly generates other ones. Andrew's final paragraph explains what we should do in situations like this.