File.separator vs FileSystem.getSeparator() vs System.getProperty("file.separator")?

Question

There seems to be three identical ways to get the platform-dependent "file separator" platform-independently:

• java.io.File.separator

• java.nio.file.FileSystems.getDefault().getSeparator();

• System.getProperty("file.separator")

How do we decide when to use which?

Is there even any difference between them?

Chimerical

Aren't you actually getting the platform-dependent file separator here? Just in a platform-independent manor. – Osmose

@Steiny, Yea, updated. – Chimerical

A typical Java Question has at least 3 or more answers – Dharma

Answer 1

System.getProperties() can be overridden by calls to System.setProperty(String key, String value) or with command line parameters -Dfile.separator=/

File.separator gets the separator for the default filesystem.

FileSystems.getDefault() gets you the default filesystem.

FileSystem.getSeparator() gets you the separator character for the filesystem. Note that as an instance method you can use this to pass different filesystems to your code other than the default, in cases where you need your code to operate on multiple filesystems in the one JVM.

Perceptible

Cool =D Btw could you elaborate on the part on "operating multiple filesystems" ? – Chimerical

@Chimerical In theory, if I wrote a new filesystem (BringerFS) that had a separator character of ":" and you had a machine with 2 partitions, one in NTFS and one in BringerFS, this functionality would allow you to use both (assuming I also wrote a Java Filesystem provider). – Perceptible

I mean practically is it useful, like say someone had 2 partitions one Windows and one UNIX, and he is running my app (on his Windows partition), is that the class able to access his UNIX file-system? (I couldn't really test this because I do not have another FileSystem installed.) – Chimerical

I suspect that most drivers for filesystems on Windows perform the translation to a 'Windows-style' filesystem API so that it allows the OS and non-portable apps to work. Practical usage would have to be for an OS that supports weird and wonderful filesystems without a fixed paradigm like Windows. – Perceptible

Oh, and to answer your other question - you would have a different FileSystem instance for each file system you dealt with. – Perceptible

hm I don't quite understand what do you mean when you say for each file system I "dealt with". So in the example above (1 physical hard disk with 2 primary partitions, 1 with Windows installed and 1 with UNIX installed, and app is running on Windows) how many instances of FileSystem would the app show? – Chimerical

You would use this method - FileSystems.getFileSystem(URI uri) - if you can access the filesystem from the URI then you can use it. If your Windows app can access the URI of the other partition then you can access it this way. Are you confusing Operating System (UNIX/Windows) and File System (FAT32, NTFS, EXT3)? – Perceptible

yes I think your last sentence made me clear some doubts but isn't a UNIX guaranteed not to use the same file system than Windows? – Chimerical

@Chimerical You can install Linux on NTFS, but it isn't done often because Linux NTFS support isn't/wasn't great. NTFS is the standard Windows filesystem nowadays. – Perceptible

experimenting with java 8 on windows, if you do override -Dfile.separator to anything other than backslash, java is unlikely to find your main class. – Fadeout

@Fadeout I didn't say it was a good idea just that it was possible! – Perceptible

Answer 2

If your code doesn't cross filesystem boundaries, i.e. you're just working with one filesystem, then use java.io.File.separator.

This will, as explained, get you the default separator for your FS. As Bringer128 explained, System.getProperty("file.separator") can be overriden via command line options and isn't as type safe as java.io.File.separator.

The last one, java.nio.file.FileSystems.getDefault().getSeparator(); was introduced in Java 7, so you might as well ignore it for now if you want your code to be portable across older Java versions.

So, every one of these options is almost the same as others, but not quite. Choose one that suits your needs.

Uniplanar

Is java.io deprecated in favor of java.nio ? – Chimerical

@Pacerier: no, it is not deprecated. java.io is a bit lower level than java.nio, but still very and widely useful. You can see the differences here: blogs.oracle.com/slc/entry/javanio_vs_javaio. nio does not replace io, it extends it in multiple ways (and uses io under the hood). – Uniplanar