This one works for me:

return Path.of(ClassLoader.getSystemResource(resourceName).toURI());

java is emitting build\someFile.txt as you'd expect. To be specific, java emits a byte sequence to standard out which then goes on a trip. That goes into the OS, the OS sends it to whatever's hooked up to your java proces's standard out which at some point presumably takes those bytes, converts it back to a string, and then does something with that. Hopefully in this wild adventure eventually somewhere something turns it into a little picture of some characters and these, eventually, are rendered onto your screen, and from there, into your eyeballs.

Something in that wild adventure is applying backslash escaping. Terminals don't do it, so something else that you did not mention in your question is doing that. Java certainly doesn't do it. Something else is. If you just write this extremely basic:

class Test {
  public static void main(String[] args) throws Exception {
    Path x = Path.of("foo/bar.txt");
    System.out.println(x);
  }
}

and run that on a stock windows in a stock-standard windows cmd.exe terminal that prints foo\bar.txt as you'd expect.

Check the chain of apps that are in between the java process and your eyeballs. One of em is messing this up. If you need some help with this process, edit the question and explain in excruciating detail (because you probably don't know what's relevant, this mojibake / terminal stuff can be tricky like that) each and every app or thing that could possibly be in between. Are you running this within an IDE? Which one, and how. Are you running this on windows subsystem for linux? Mention that, how you're doing it, which commands you're typing in, and so on.

Path is a class that represents a path. Anything where you typically already have a Path involves the methods located here.

Paths is a set of utilities. These utilities produce Path objects from other types of input. The utilities do not require having a Path ahead of time. They are convenience wrappers for common, often repeatedly used code, to reduce the need to cut-and-paste.

Here is an example of using Paths:

/* I have a String, but need a Path */
Path path = Paths.get("/home/user/.config");

Here is an example of using Path:

/* I have a Path, but need a String */
String name = path.toString();

The reason why a Utility class like Paths is required is a combination of a number of factors:

1. Path is an interface, so direct calls of its constructor are not possible; as it has no constructor.
2. String is a final class, and a class where modifying it would probably be far more difficult to present as an alternative than creating a utility class. So while "/home/user/.config".toPath() might be a valid object-oriented way of doing things, legacy code prevents adding that without more deliberation.
3. URI has pressures on it similar to the pressures described above on String.

When they added in the NIO Path class, they wanted their code to be reviewed and integrated into the core Java library.

Stuff that is easy to get others to add to a library has the following characteristics:

1. You don't mess with existing parts of the library in ways that are exposed by the established library call interface (doing this disrupts users of the library, as now they need to rewrite their programs).
2. You have a backout plan that is easy (this is critical because you might not be able to deliver on time)

If they took the approach of modifying String and URI to have a getPath(...) function, then they would have increased the difficulty in getting their code integrated into the Java standard library.

Edit : You don't have to instantiate every attributes of your object within your constructors, if you don't instantiate them they will be equal to null.

To create a new nio Path object :

Copyimport java.nio.file.Path;
import java.nio.file.Paths;

Path p = Paths.get("/tmp/myfile");