This question is related to my question

Jetty 11.0.11 - 404 on html file in \src\main\webapp\static - maven embedded fat jar

What --EXACTLY-- does "jar:file" mean as a Java resource reference, vs. just "file:"?

And how is that influenced by the operating system ran under?

E. g. using this resource reference in Jetty webserver, in Windows with Oracle JDK 17, files are found as resources and parsed by Jetty webserver:

file:///D:/Projects/verdi_2/target/classes/static/,AVAILABLE}{file:/D:/Projects/verdi_2/target/classes/static}

Using this resource reference in Jetty webserver, in Ubuntu Linux 20.04 LTS with Oracle JDK 17, NO files are found and nothing can be parsed by Jetty webserver:

jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/static

Is there a difference in how a Linux version of JDK interprets "jar:file" vs. how a Windows version of the JDK interprets "jar:file"?

CodePudding user response：

file: is the beginning of a general file url. jar:file: is that for a jar file particularly, with a view to referring (usually) to a particular entry in a jar. Here's an example you can run (obviously with your own jar url) where you can save an entry as a file (given by the parameter to the app)

import java.nio.file.Paths;
import java.nio.file.Files;
import java.net.URL;

public class JarUrl {
    public static void main(String[] args) {
        try {
            URL url = new URL("jar:file:root.jar!/root/a/b.txt");
            Files.copy(url.openStream(), Paths.get(args[0]));
        }
        catch(Throwable t) {
            t.printStackTrace();
        }
    }
}

CodePudding user response：

What --EXACTLY-- does "jar:file" mean as a Java resource reference, vs. just "file:"?

You're mischaracterising the URL a little bit. The string until the first : decides the 'scheme' of a URL, so, the pertinent question is: How does jar: work. The file: part is a smaller aspect of a sub-part of the jar bit.

How does jar: work

The format is jar:(URL-of-jar)!(path-inside-jar)

Where URL-of-jar is itself a valid URL (and file: is just one way to do that. So is http, for that matter), and path-inside-jar is not a URL but a path.

The meaning is: First, resolve the 'URL-of-jar' URL. This gets you a jar file. Then, open the jar file, and retrieve the resource at the stated path.

So, to pull this one apart:

jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/static

The jar is located at URL file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar and the resource it is referring to is the /static resource inside the jar found at the given URL.

How does file: work

That's not java-specific; file: is a generally available URL scheme. You can even type it in a web browser. The more general URL formatting scheme is scheme://server/resource, but with file:, server doesn't apply (it is by definition local to the system you are on), so usually its put as file:///foo, i.e. - an empty 'server' part. Because 3 slashes is a drag to type, I guess, file:/resource is allowed by some 'URL parsers', including java's in this regard, so, file:/usr/... simply maps straight to a local folder: /usr/src/verdi/verdi-12-JDK-etc, as in, if you type ls /usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar on the command line on your system, it would show a result (and if it does not, this URL would fail to find anything).

And how is that influenced by the operating system ran under?

It isn't. file URLs are a general concept that work on any platform. Of course, /usr/src/verdi/etc is never going to work correctly on a windows platform. Or on anybody else's machine. The problem isn't "Oh no! This won't run on another OS!". The problem with file URLs, especially absolute ones, is "Oh no! This will not run on any machine other than this one!".

file:///D:/Projects

I've explained the triple slashes earlier. This is the standard windows 'scheme' for how to stick paths in file URLs: Always forward slashes (even though windows normally uses backslashes), and treat the disk letter as if it is a 'drive' in the 'root': /D:/Project is URL-ese for:

D:
cd \Project

There is no difference in OS at all - file: URLs are handled by 'interpret this file URL the way any file URL would be interpreted on this machine'.