In a popular answer regarding the difference between class loading methods, Jon Skeet has stated,
Classloader resource paths are always deemed to be absolute.
An even more popular answer affirms this statement with an example.
ClassLoader.getResourceAsStream(path)
will consider all paths to be absolute paths. So callingString.getClassLoader().getResourceAsString("myfile.txt")
andString.getClassLoader().getResourceAsString("/myfile.txt")
will both look for a file in your classpath at the following location:./myfile.txt
.
Disregarding the fact that the example won't compile, consensus indicates a leading forward slash is irrelevant to the ClassLoader.
A simple test shows otherwise.
Foo.class.getClassLoader().getResource("test.xml") // file
Foo.class.getClassLoader().getResource("/test.xml") // null
I have simply added the path files/test.xml
to the classpath of a test project, with a class named Foo
containing a main()
method printing out the results of those two calls. What am I missing, since hundreds of people have up-voted the aforementioned answers? Are ClassLoaders absolute, or do they depend on the structure of the input name?
This Oracle blog post was helpful to my understanding.
The method which ultimately constructs a URL from the resource name is URLClassPath.JarLoader.checkResource().
Apparently not.
It is up to the class loader to interpret name
in getResource(name)
.
Examining the source code of URLClassLoader
, eventually it calls
new URL(baseURL, name)
It is important here whether name
is absolute or relative
It is possible that, for some baseURL
, absolute /foo/bar
and relative foo/bar
have the same effect. In particular, this is always the case for "jar file URL" in classpaths
baseURL: jar:file:/home/duke/duke.jar!/
foo/bar -> jar:file:/home/duke/duke.jar!/foo/bar
/foo/bar -> jar:file:/home/duke/duke.jar!/foo/bar
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With