Quarkus: getResource with absolute resource name is not working in native image

[rdehuyss]

Describe the bug
Absolute resource names are not found in native images (with beginning '/')

Expected behavior
Absolute resource names should be found

To Reproduce
Steps to reproduce the behavior:

Create any Jax-rs resource and add a property file.

@Path("jobs")
@ApplicationScoped
public class JobResource {

    @GET
    @Path("/simple-job")
    @Produces(MediaType.APPLICATION_JSON)
    public SimpleResponse simpleJob(@DefaultValue("World") @QueryParam("name") String name) throws IOException {
        final ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
        String propteryFile = "/org/jobrunr/examples/webapp/api/test.properties";
        final URL resource1 = contextClassLoader.getResource(propteryFile);
        System.out.println("Property file exists: " + (resource1 != null));

        String propteryFile2 = "org/jobrunr/examples/webapp/api/test.properties";
        final URL resource2 = contextClassLoader.getResource(propteryFile2);
        System.out.println("Property file exists: " + (resource2 != null));

        return new SimpleResponse("Job Enqueued");
    }
}

In JVM mode the output is as follows:
Property file exists: true
Property file exists: true

In native mode the output is as follows:
Property file exists: false
Property file exists: true

Unless I don't understand the spec correctly, I think resources with beginning '/' should be handled as absolute resources: https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getResource-java.lang.String-

Configuration
Pom.xml quarkus build config:

                    <plugin>
                        <groupId>io.quarkus</groupId>
                        <artifactId>quarkus-maven-plugin</artifactId>
                        <version>${quarkus-plugin.version}</version>
                        <executions>
                            <execution>
                                <goals>
                                    <goal>native-image</goal>
                                </goals>
                                <configuration>
                                    <enableHttpUrlHandler>true</enableHttpUrlHandler>
                                    <additionalBuildArgs>--allow-incomplete-classpath,-H:IncludeResources=*/*.properties$,-H:Log=registerResource:verbose</additionalBuildArgs>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>

Environment (please complete the following information):

• Output of uname -a or ver:
  Linux rdehuyss-laptop 5.3.0-45-generic #37-Ubuntu SMP Thu Mar 26 20:41:27 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
• Output of java -version:
  openjdk version "11.0.7" 2020-04-14
  OpenJDK Runtime Environment (build 11.0.7+10-post-Ubuntu-2ubuntu219.10)
  OpenJDK 64-Bit Server VM (build 11.0.7+10-post-Ubuntu-2ubuntu219.10, mixed mode, sharing)
• GraalVM version (if different from Java): graalvm-ce-java8-20.0.0
• Quarkus version or git rev: 15.1
• Build tool (ie. output of mvnw --version or gradlew --version):
  Apache Maven 3.6.1
  Maven home: /usr/share/maven
  Java version: 11.0.7, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64
  Default locale: en_US, platform encoding: UTF-8
  OS name: "linux", version: "5.3.0-45-generic", arch: "amd64", family: "unix"

Additional context
(Add any other context about the problem here.)

[geoand]

Is the JVM version you are referring to the regular java -jar .. execution or dev mode?

[rdehuyss]

It is dev mode

[geoand]

I assume that java -jar ... behaves the same way as native-mode?

[rdehuyss]

Indeed, just double checked...

As it is not clear to me yet - is this a bug in Quarkus or GraalVM?

[geoand]

That's what I thought. So it's actually the dev mode classloader being too lenient here

[rdehuyss]

That's what I thought. So it's actually the dev mode classloader being too lenient here

Why too lenient? In all other JVM's (I have tests for 12 different JVM's) the leading slash works... It seems that the others are too strict?

[geoand]

Sorry, didn't you just say that java -jar ... behaves the same way as the native mode i.e. it doesn't load the resource if it has a leading slash?

[rdehuyss]

Yes - my mistake - doing further testing to find root cause.

[rdehuyss]

Ok, my mistake - it's because I'm using the TCCL instead of the normal classloader.

Indeed - the dev mode classloader is too lenient.

[geoand]

Yeah, we should address that