The answer is “Don’t use it!”
A file separator is a character that is used to separate directory names that make up a path to a particular location. This character is operating system specific. On Microsoft Windows, it is a back-slash character (), e.g. C:myprojectmyfilesome.properties. On Mac OS and unix based operating systems, it is a forward slash (/) character, e.g. /myproject/myfile/some.properties.
As the Java API documentation on File class states:

The default name-separator character is defined by the system property file.separator, and is made available in the public static fields separator and separatorChar of this class.

The usual way to construct a path is either

1
String fs = File.separator;

or

1
String fs = System.getProperty("file.separator");

and then construct a path like

1
String myPropsPath = "core" + fs + "main.properties";

Now, why did I say that you should not use file separator when loading resources? The reason is that a file and a resource is not the same thing. In most cases a resource will be a file on the disk and even is you use file separator you would not have any problems loading it (Java is smart).
However, there is a corner case, which will hit you if you are not prepared. Consider the following example:

1
URL url = this.getClassLoader().getResource(myPropsPath);

This is how you get a URL to a resource. The code works fine most of the time. The resource being looked up is found on the classpath. The only problem is when this resource resides inside an archive (ZIP, JAR, WAR, etc.) and the code is executed on Windows platform.
I discovered it when I was debugging some code that was constructing a path using the file separator character and the application was deployed as a WAR module. This WAR was not exploded by the application server and the application server was running on Microsoft Windows.
Why it did not work? Simply, the path was incorrect. It took me a while to figure out why. I checked the value in myPropsPath. It looked fine. It was using the back-slashes as it should on Windows. The file was in the right location. And then I noticed a difference. There was another file beside it. The application loaded it just fine. The difference was that its path was not constructed this way, it was hard-coded in the XML file and it used forward-slashes as the file separators.
Then I looked at the JavaDoc on ClassLoader.getResource(String) method and as Stuart Pearce would say: “I saw the carrot at the end of the tunnel.” ClassLoader requires a name of the resource as a /-separated path name. So, Windows back-slashes won’t work.
Just to show you some outputs, consider the following class

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
01: public class Loader {
02:
03:   public static void main(String[] args) {
04:     String separator = args[0];
05:     System.out.println("Separator is '" + separator + "'");
06:     String path = "com" + separator + "atlassian" + separator + "slash"
07:                 + separator + "SomeClass.class";
08:     System.out.println("Path is      '" + path + "'");
10:     URL url = Loader.class.getClassLoader().getResource(path);
11:     System.out.println("URL is       '" + url + "'");
12:     if (url != null) {
13:       try {
14:         File file = new File(url.toURI());
15:         System.out.println("File exists: " + file.exists());
16:       } catch (URISyntaxException e) {
17:         System.out.println("Error in URI syntax");
18:       } catch (IllegalArgumentException e) {
19:         System.out.println(e.getMessage());
20:       }
21:     }
22:   }
23: }

When running this little program, we manually set the file separator character as the first parameter passed into the main method on line 4. Then we construct a path on line 6. We try to get the URL to the resource on line 10. If the URL is retrieved and not null, we try to create a File object using the URI from URL (line 14).
There are the following 4 combinations that we will test:
1. and resource in JAR file;
2./ and resource in JAR file;
3. and resource as a file on the disk;
4./ and resource as a file on the disk.
The first case gives the following output:

1
2
3
Separator is ''
Path is      'comatlassianslashSomeClass.class'
URL is       'null'

As you can see constructing a URL with back-slashes is not valid.
The second test scenario produces:

1
2
3
4
Separator is '/'
Path is      'com/atlassian/slash/SomeClass.class'
URL is       'jar:file:/C:/SomeJAR/release/somejar.jar!/com/atlassian/slash/SomeClass.class'
URI is not hierarchical

The last message indicates that URL is correct, however it is not a file and cannot be accessed this way.
The third and fourth run prints out:

1
2
3
4
Separator is ''
Path is      'comatlassianslashSomeClass.class'
URL is       'file:/C:/SomeJAR/bin/com%5catlassian%5cslash%5cSomeClass.class'
File exists: true
1
2
3
4
Separator is '/'
Path is      'com/atlassian/slash/SomeClass.class'
URL is       'file:/C:/SomeJAR/bin/com/atlassian/slash/SomeClass.class'
File exists: true

As you can see Java is clever and when you are accessing files, it can handle both forward and back-slashes just fine.
The moral of this story is, use system-specific file separator only when working with files and when displaying a path to the user. For all other cases use forward slash.