java.io.File class represents a file name on the host system. It attempts to abstract system-dependent file name features like the path separator character. There are two ways to reference a file, relative and absolute. Absolute addressing gives a complete path to a file, starting with the disk and working its way down. How this is represented varies from operating system to operating system. Here are some examples:
Unix: "/home/users/elharo/file1"
DOS: "C:\home\users\elharo\file1"
MacOS: "Macintosh HD:home:users:elharo:file1"
Worse yet there's no guarantee that the Mac's primary hard drive is called "Macintosh HD" or that it even has such a disk. On Unix /home and /home/users may be on completely different disks, perhaps even on different machines. For these and more reasons absolute pathnames are a royal pain to work with and should be avoided whenever possible.
Relative addressing, which should be used if possible, doesn't give the complete path to the file. Instead it gives the path relative to some other known file. A relative pathname may point to a file in the same directory as a known file by only giving its name. Other times it may point to a file in a subdirectory of a known directory.
Generally one directory is set as the current directory. This is where methods that look for files are relative to. Normally this is the directory in which you started running the application.
java.io.File can hold a directory name equally as well as a filename.
File object is not a file handle. Just because you have a File object does not mean that the equivalent file actually exists on the disk. There are methods you can use to determine whether a File object refers to a real file or not (specifically exists()).