Passing Unix Like Path: Why This Java Code Working on Windows Machine

I am confused with a piece of code which is by the way working, but my question is why it is working? Have a look at below code

public String GetQuery(int QueryIndex) throws IOException {
		String realPath = (FileHelper.class.getResource("FileHelper.class")).toString().replace("lib/FileHelper.class", "conf/").replace("file:/", "").replace("%20", " ");

        //--->Printing value of realPath
		System.out.println(realPath);
        
        //-->Creating an object of file but adding Slash before path
        //--->Works with both Widnows and Linux machine for some reason.
		File QueryFile = new File("/"+realPath + "cygnus.dll");

		BufferedReader brReader = new BufferedReader(new FileReader(QueryFile));
		String TempContent;
		while ((TempContent = brReader.readLine()) != null) {
			if (TempContent.split(Config.COLSEP)[0].equals("Query"+QueryIndex)) {
				brReader.close();
				return TempContent.replace("Query"+QueryIndex+Config.COLSEP, "");
			}
		}
		brReader.close();
		return TempContent;
	}

Console Output of System.out.println(realPath)

D:/eclipse/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp1/wtpwebapps/cygnus/WEB-INF/classes/com/technobee/cygnus/conf/

Complete path of file passed in File constructor

/D:/eclipse/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp1/wtpwebapps/cygnus/WEB-INF/classes/com/technobee/cygnus/conf/cygnus.dll

Now we can see that the we have this slash before the path and the functionality is still working. So is this an expected behavior?

The code looks very brittle and you should fix it rather than passing on the hack especially if you have other places to change in similar manner. The technique will only work if your classes / resources are found in a file system and you use File.

If you deployed to app server with war/jar rather than exploded filesystem, the path returned by returned by getResource() cannot be interpreted correctly with File or Path as it will contain extra parts for the URI such as "jar:" and "!" for paths inside an archive.

Instead, its very easy fix to switch to properties for the locations / other resources to read, or you can locate the resource using InputStream / getResourceAsStream with some String manipulation based upon the package name of the search class FileHelper.class.getPackageName(), leading to:

 InputStream in = FileHelper.class.getResourceAsStream("/packagea/packageb/conf/cygnus.dll")`.

On Windows, File resolves paths like "/C:/abc" to be same as new File("C:\\abc"). However the same trick with Path.of("/C:/abc") fails:

Exception java.nio.file.InvalidPathException: Illegal char <:> at index 2: /C:/abc

/ denotes the file root (on any sensible platform), so doing /somePath/someOtherPath on windows assumes that you mean C:\somePath\someOtherPath. If you specify another drive after the /, that drive gets used instead.

> "... Now we can see that the we have this slash before the path and the functionality is still working. So is this an expected behavior?"

A system path is just a notation—it's not a syntax.

There is not a standardization for a notation—as the notation is, in and of itself, the standard.

There is an RFC for the file URI scheme, which will define the grammar of its path element.
RFC 8089 – The "file" URI Scheme.

From here, we can at least see what is used by an abstraction that encloses a path notation.

Here is the ABNF, from "Section 2, Syntax",

file-URI       = file-scheme ":" file-hier-part
file-scheme    = "file"
file-hier-part = ( "//" auth-path )
               / local-path
auth-path      = [ file-auth ] path-absolute
local-path     = path-absolute
file-auth      = "localhost"
               / host

And, path-absolute, as inherited by RFC 3986, under "Section 3.3, Path",

path-absolute = "/" [ segment-nz *( "/" segment ) ]
segment       = *pchar
segment-nz    = 1*pchar
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

It would appear that it is simply a forward-slash delimited set of values, with a required forward-slash at the start.

So, you should expect to see different results from different applications that are attempting to derive data via a provided path notation.

The syntactic value of the path is left to the resolving program, or procedure, as it is not contained within the string, and is just a notation.

This is similar to why some applications will allow for interchangeable forward and backward slashes—e.g., "C:/value", and "C:\value" both work—and others will throw an error.