Thank you for the confirmation. I was actually a bit surprised that directories were accessible as resource, the behavior of the runtime image makes more sense to me.
Currently Micronaut depends on this feature/bug/unclear spec, so before trying to resolve this I just wanted to make sure this is indeed the expected behavior. Robert From: Alan Bateman <alan.bate...@oracle.com> Sent: woensdag 12 juni 2024 10:31 To: rfscho...@apache.org; 'jigsaw-dev' <jigsaw-dev@openjdk.org> Subject: Re: loading regular/directory resources via classloader On 12/06/2024 08:18, Robert Scholte wrote: When running this using the classpath or modulepath I’ll get true for every line. However, when creating the application with jlink, only regular resources return true(i.e. the second and fourth log statement), the “directories” return false. Is this difference intended behavior? The parameter provided to getResource is a resource name. The getResource/getResourceAsStream methods don't specify if "directories" are located as resources with that method. ModuleReader is the only class (that I can think of) that set expectations on this. When exploded on the file system then there is a sensible mapping. This means using the resource name "META-INF/micronaut/io.micronaut.inject.BeanDefinitionReference" and "META-INF/micronaut/io.micronaut.inject.BeanDefinitionReference/" will return a file URL to the directory. Whether getResourceAsStream returns a useful InputStream is another question as it's highly platform specific if you can open a directory as a regular file. For JAR files then it depends on whether the JAR file has entries for directories. JAR files are based on the ZIP format and some tooling will create JAR files that don't have entries for directories (they aren't needed). So depending on what created the JAR file then getResource method may return a jar URL to a "directory entry" or it may return null. For modules in a a run-time image then there isn't the equivalent of directories so #2 and #4 returning null is expected. It would be technically feasible to synthesize entries to have this work in many more cases, but not clear if it's worth doing. We should at least surface expectations in the Class/ClassLoader.getResourceXXX API docs as the notion of "resource" has never been clearly specified. -Alan
