## Difference between File.separator and slash in paths

### Question

What is the difference between using File.separator and a normal / in a Java Path-String?

In contrast to double backslash \\ platform independence seems not to be the reason, since both versions work under Windows and Unix.

public class SlashTest {
@Test
public void slash() throws Exception {
File file = new File("src/trials/SlashTest.java");
assertThat(file.exists(), is(true));
}

@Test
public void separator() throws Exception {
File file = new File("src" + File.separator + "trials" + File.separator + "SlashTest.java");
assertThat(file.exists(), is(true));
}
}


To rephrase the question, if / works on Unix and Windows, why should one ever want to use File.separator?

2017/08/21
1
204
8/21/2017 7:29:50 AM

With the Java libraries for dealing with files, you can safely use / (slash, not backslash) on all platforms. The library code handles translating things into platform-specific paths internally.

You might want to use File.separator in UI, however, because it's best to show people what will make sense in their OS, rather than what makes sense to Java.

Update: I have not been able, in five minutes of searching, to find the "you can always use a slash" behavior documented. Now, I'm sure I've seen it documented, but in the absense of finding an official reference (because my memory isn't perfect), I'd stick with using File.separator because you know that will work.

2010/03/10
248
3/10/2010 2:33:46 PM

Although using File.separator to reference a file name is overkill (for those who imagine far off lands, I imagine their JVM implementation would replace a / with a : just like the windows jvm replaces it with a \).

However, sometimes you are getting the file reference, not creating it, and you need to parse it, and to be able to do that, you need to know the separator on the platform. File.separator helps you do that.

2010/03/10

OK let's inspect some code.
File.java lines 428 to 435 in File.<init>:

String p = uri.getPath();
if (p.equals(""))
throw new IllegalArgumentException("URI path component is empty");

// Okay, now initialize
p = fs.fromURIPath(p);
if (File.separatorChar != '/')
p = p.replace('/', File.separatorChar);


And let's read fs/*(FileSystem)*/.fromURIPath() docs:

java.io.FileSystem
public abstract String fromURIPath(String path)
Post-process the given URI path string if necessary. This is used on win32, e.g., to transform "/c:/foo" into "c:/foo". The path string still has slash separators; code in the File class will translate them after this method returns.

This means FileSystem.fromURIPath() does post processing on URI path only in Windows, and because in the next line:

p = p.replace('/', File.separatorChar);


It replaces each '/' with system dependent seperatorChar, you can always be sure that '/' is safe in every OS.

2017/01/03

Well, there are more OS's than Unix and Windows (Portable devices, etc), and Java is known for its portability. The best practice is to use it, so the JVM could determine which one is the best for that OS.

2010/03/10

Although it doesn't make much difference on the way in, it does on the way back.

Sure you can use either '/' or '\' in new File(String path), but File.getPath() will only give you one of them.

2010/03/10

Late to the party. I'm on Windows 10 with JDK 1.8 and Eclipse MARS 1.
I find that

getClass().getClassLoader().getResourceAsStream("path/to/resource");

works and

getClass().getClassLoader().getResourceAsStream("path"+File.separator+"to"+File.separator+"resource");

does not work and

getClass().getClassLoader().getResourceAsStream("path\to\resource");

does not work. The last two are equivalent. So... I have good reason to NOT use File.separator.

2015/12/01