142

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

How do we decide when to use which?

Is there even any difference between them?

Pacerier
  • 76,400
  • 86
  • 326
  • 602

2 Answers2

151

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.

Bringer128
  • 6,469
  • 2
  • 31
  • 57
  • 2
    Cool =D Btw could you elaborate on the part on "operating multiple filesystems" ? – Pacerier Nov 10 '11 at 05:52
  • 4
    @Pacerier 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). – Bringer128 Nov 10 '11 at 06:05
  • 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.) – Pacerier Nov 10 '11 at 06:21
  • 1
    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. – Bringer128 Nov 10 '11 at 06:57
  • Oh, and to answer your other question - you would have a different `FileSystem` instance for each file system you dealt with. – Bringer128 Nov 10 '11 at 06:58
  • 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? – Pacerier Nov 10 '11 at 07:06
  • You would use this method - [FileSystems.getFileSystem(URI uri)](http://download.oracle.com/javase/7/docs/api/java/nio/file/FileSystems.html#getFileSystem(java.net.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)? – Bringer128 Nov 10 '11 at 07:23
  • 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? – Pacerier Nov 10 '11 at 10:41
  • @Pacerier You can [install Linux on NTFS](http://answers.yahoo.com/question/index?qid=20070530052145AAebKWN), but it isn't done often because Linux NTFS support isn't/wasn't great. NTFS is the standard Windows filesystem nowadays. – Bringer128 Nov 11 '11 at 02:31
  • 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. – philwalk Aug 08 '18 at 21:55
  • @philwalk I didn't say it was a good idea just that it was possible! – Bringer128 Aug 09 '18 at 18:02
31

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.

Asish AP
  • 4,385
  • 1
  • 25
  • 49
darioo
  • 43,550
  • 10
  • 71
  • 102
  • Is `java.io` deprecated in favor of `java.nio` ? – Pacerier Nov 10 '11 at 05:53
  • 15
    @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: https://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). – darioo Nov 10 '11 at 05:56