URL, URI and local files

[Piet Souris]

Today I tried java's URLConnection, trying to read a local Json-file  and to compare the lot with javascripts fetch(). I came up with

URL u = new URL("file://localhost/G:/JsonProbeersels/src/jsonprobeersels/Resources/expenses.json");
URLConnection connection = u.openConnection();
InputStream inputstream = connection.getInputStream();
try( var stream = (new BufferedReader(new InputStreamReader(inputstream)).lines())) {
    var js = stream.collect(joining("\n"));
    System.out.println(js);
}

I noticed that new URL is deprecated, and that I should use URI.toURL:

URL u = new URI("file://localhost/G:/JsonProbeersels/src/jsonprobeersels/Resources/expenses.json").toURL();

Am I using the URL and the URI in a correct way? Is there a better way?

Thanks!

[Carey Brown]

This example  is the way I remember doing it.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.URI;
import java.net.URISyntaxException;
import java.net.URL;

public class ReadFileFromURI {
    public static void main(String[] args) {
        String fileURI = "file:///path/to/your/localfile.txt"; // Make sure to use the correct path

        try {
            readTextFileFromURI(fileURI);
        } catch (IOException | URISyntaxException e) {
            System.err.println("Error reading the file: " + e.getMessage());
        }
    }

    public static void readTextFileFromURI(String fileURI) throws IOException, URISyntaxException {
        URI uri = new URI(fileURI);
        URL url = uri.toURL();

        try (BufferedReader reader = new BufferedReader(new InputStreamReader(url.openStream()))) {
            String line;
            while ((line = reader.readLine()) != null) {
                System.out.println(line);
            }
        }
    }
}

Also, "localhost" is unnecessary.

[Piet Souris]

Thanks, Carey.

If I leave out 'localhost/', both with the URL and the URI, I get this error:

Exception in thread "main" java.net.UnknownHostException: G
	at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:567)
	at java.base/java.net.Socket.connect(Socket.java:751)
	at java.base/sun.net.ftp.impl.FtpClient.doConnect(FtpClient.java:1045)
	at java.base/sun.net.ftp.impl.FtpClient.tryConnect(FtpClient.java:1010)
	at java.base/sun.net.ftp.impl.FtpClient.connect(FtpClient.java:1102)
	at java.base/sun.net.ftp.impl.FtpClient.connect(FtpClient.java:1088)
	at java.base/sun.net.www.protocol.ftp.FtpURLConnection.connect(FtpURLConnection.java:314)
	at java.base/sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:420)
	at pietsjavaprobeersels01.FetchURL.main(ProbeerselURLConnection.java:32)
C:\Users\Piet\AppData\Local\NetBeans\Cache\21\executor-snippets\run.xml:111: The following error occurred while executing this line:
C:\Users\Piet\AppData\Local\NetBeans\Cache\21\executor-snippets\run.xml:68: Java returned: 1

But I may be doing something wrong.

Edit: if I do not start with 'file://", then I do indeed not need the localhost. Complicated stuff...

[Paul Clapham]

The stack trace suggests you are trying to connect to an FTP server. In which case a file:// URL would be the wrong choice anyway.

[Stephan van Hulst]

Piet Souris wrote:If I leave out 'localhost/', both with the URL and the URI, I get this error:

Do you mean:
file://G:/JsonProbeersels/src/jsonprobeersels/Resources/expenses.json
Yeah, that wouldn't work. When you write it like that, it interprets "G" as a host name.

It's relatively easy to figure out how to construct an URL of any kind if you know a few simple rules. Most URLs are of one of the the following two variants:
<scheme>://<authority>/[<path>][?<query>][#<fragment] <scheme>:/<path>[?<query>][#fragment]
Simply put, if you have two slashes after the scheme, then it means you will be specifying an authority. For the "file" scheme, the authority is really just the domain name of the system that you want to retrieve the file from, and file URLs don't have a query nor a fragment.

Here are two examples:
file://fileserver.piet-souris.nl/C:/path/to/file.json file:/C:/path/to/file.json
Now, the reason that the URL that Carey gave would also work, is because it's allowed to specify an empty authority, which for the "file" scheme means that the authority defaults to localhost. So the following URLs are all equivalent:
file://localhost/G:/ file:///G:/         (empty authority defaults to localhost) file:/G:/           (null authority defaults to localhost)

[Tim Holloway]

To refine Stephan's response:

If you omit all leading slashes after "file:", that indicates a relative path location (on the local host). Relative paths should be used only with care.

The generally preferred syntax for a file resource path is "file:///directory/directory/file". In Windows, the top-level directory would be the drive ID, and if omitted assumes the currently logged drive.

UNC filename paths are valid in file URLs as well.

Finally, if memory serves, an alternative drive ID syntax allow using "|" following the drive ID, viz. "file:///G|/path/to/file". That can be used to eliminate confusion, since ":" has a specific meaning for URLs.

And, of course, masochists can use actual Windows file paths, allowing for the fact that the backslash character also has a specific meaning: "file:///G:\\path\\to\\file". But aside from the obvious hazards, that makes writing portable code harder.

[Carey Brown]

Tim Holloway wrote:"file:///G|/path/to/file"

This is the one I'm familiar with..

[Piet Souris]

Stephan van Hulst wrote:
Do you mean:
file://G:/JsonProbeersels/src/jsonprobeersels/Resources/expenses.json

Yes,

Thank you, Stephan and Tim. When I started, I only knew URLs starting with 'https://', so I thought of using 'file://', as we say in Dutch 'not hindered by any relevant knowledge'.

[Tim Holloway]

URLs can support all sorts of schemes. For example "gopher:" or "ftp:". Gopher was an old pre-google search engine, no longer supported.

However, to be useful, you'd feed the URL to some sort of consumer (for example, a web client). In which case, the consumer would typically inquire of a registry of schemes to see if it could process that scheme.  If the registry in question does not recognize the scheme, it will take a default action. For example, my FireFox browser will send the unparseable URL "fool://www.motley.com" out to its default search engine. The Linux "curl" command, on the other hand reports "curl: (1) Protocol "fool" not supported".

(Note: edited example URL because original was incorrectly pasted).