In this chapter, we’re going to talk about the Java file I/O API. To
be more precise, we are going to talk about two file APIs: first, there is
the core java.io File I/O facility that
has been part of Java since the beginning. Then there is the “new”
java.nio.file API introduced in Java 7.
In general the NIO packages, which we’ll cover in detail later and which
touch upon not only files but all types of network and channel I/O, were
introduced to add advanced features that make Java more scaleable and
higher performance. However, in the case of file NIO, the new package is
also just somewhat of a “do-over” on the original API. In movie terms, you
can think of the two APIs as the “classic” and the “reboot” of the series.
The new API completely duplicates the functionality of the original, but
because the core API is so fundamental (and in some cases simpler), it is
likely that many people will prefer to keep using it. We’ll start with the
classic API centering on java.io.File
and later we’ll cover the new API, which centers on the analogous java.nio.Path.
Working with files in Java is easy, but poses some conceptual problems. Real-world filesystems can vary widely in architecture and implementation: think of the differences between Mac, PC, and Unix systems when it comes to filenames. Java tries to mask some of these differences and provide information to help an application tailor itself to the local environment, but it leaves a lot of the details of file access implementation dependent. We’ll talk about techniques for dealing with this as we go.
Before we leave File I/O we’ll also show you some tools for the special case of application “resource” files packaged with your app and loaded via the Java classpath.
The java.io.File class
encapsulates access to information about a file or directory. It can be
used to get attribute information about a file, list the entries in a
directory, and perform basic filesystem operations, such as removing a
file or making a directory. While the File object handles these “meta” operations,
it doesn’t provide the API for reading and writing file data; there are
file streams for that purpose.
You can create an instance of File from a String pathname:
FilefooFile=newFile("/tmp/foo.txt");FilebarDir=newFile("/tmp/bar");
You can also create a file with a relative path:
Filef=newFile("foo");
In this case, Java works relative to the “current working
directory” of the Java interpreter. You can determine the current
working directory by reading the user.dir property in the System Properties list:
System.getProperty("user.dir");// e.g.,"/Users/pat"
An overloaded version of the File constructor lets you specify the
directory path and filename as separate String objects:
FilefooFile=newFile("/tmp","foo.txt");
With yet another variation, you can specify the directory with a
File object and the filename with a
String:
FiletmpDir=newFile("/tmp");// File for directory /tmpFilefooFile=newFile(tmpDir,"foo.txt");
None of these File
constructors actually creates a file or directory, and it is not an
error to create a File object for a
nonexistent file. The File object
is just a handle for a file or directory whose properties you may wish
to read, write, or test. For example, you can use the exists() instance method to learn whether
the file or directory exists.
One issue with working with files in Java is that pathnames are expected to follow the conventions of the local filesystem. Two differences are that the Windows filesystem uses “roots” or drive letters (for example, C:) and a backslash (\) instead of the forward slash (/) path separator that is used in other systems.
Java tries to compensate for the differences. For example, on Windows platforms, Java accepts paths with either forward slashes or backslashes. (On others, however, it only accepts forward slashes.)
Your best bet is to make sure you follow the filename
conventions of the host filesystem. If your application has a GUI that
is opening and saving files at the user’s request, you should be able
to handle that functionality with the Swing JFileChooser class.
This class encapsulates a graphical file-selection dialog box. The
methods of the JFileChooser take
care of system-dependent filename features for you.
If your application needs to deal with files on its own behalf,
however, things get a little more complicated. The File class contains a few static variables to make this task possible.
File.separator defines a String that specifies the file separator on
the local host (e.g., / on Unix and
Macintosh systems and \ on Windows
systems); File.separatorChar
provides the same information as a char.
You can use this system-dependent information in several ways.
Probably the simplest way to localize pathnames is to pick a
convention that you use internally, such as the forward slash (/), and
do a String replace to substitute
for the localized separator character:
// we'll use forward slash as our standardStringpath="mail/2004/june/merle";path=path.replace('/',File.separatorChar);Filemailbox=newFile(path);
Alternatively, you could work with the components of a pathname and build the local pathname when you need it:
String[]path={"mail","2004","june","merle"};StringBuffersb=newStringBuffer(path[0]);for(inti=1;i<path.length;i++)sb.append(File.separator+path[i]);Filemailbox=newFile(sb.toString());
One thing to remember is that Java interprets a literal
backslash character (\) in source
code as an escape character when used in a String. To get a backslash in a String, you have to use \\.
To grapple with the issue of filesystems with multiple “roots”
(for example, C:\ on Windows), the
File class provides the static
method listRoots(), which
returns an array of File objects
corresponding to the filesystem root directories. Again, in a GUI
application, a graphical file chooser dialog shields you from this
problem entirely.
Once we have a File
object, we can use it to ask for information about and perform
standard operations on the file or directory it represents. A number
of methods let us ask questions about the File. For example, isFile() returns
true if the File represents a regular file, while
isDirectory() returns
true if it’s a directory.
isAbsolute()
indicates whether the File
encapsulates an absolute path or
relative path specification. An absolute path is
a system-dependent notion that means that the path doesn’t depend on
the application’s working directory or any concept of a working root
or drive (e.g., in Windows, it is a full path including the drive
letter: c:\\Users\pat\foo.txt).
Components of the File
pathname are available through the following methods: getName(), getPath(), getAbsolutePath(),
and getParent(). getName() returns a String for the filename without any
directory information. If the File
has an absolute path specification, getAbsolutePath() returns that path.
Otherwise, it returns the relative path appended to the current
working directory (attempting to make it an absolute path). getParent() returns the parent directory of
the file or directory.
The string returned by getPath() or getAbsolutePath() may not follow the same
case conventions as the underlying filesystem. You can retrieve the
filesystem’s own or “canonical” version of the file’s path by using
the method getCanonicalPath(). In
Windows, for example, you can create a File object whose getAbsolutePath() is
C:\Autoexec.bat but whose getCanonicalPath() is
C:\AUTOEXEC.BAT; both actually point to the same
file. This is useful for comparing filenames that may have been
supplied with different case conventions or for showing them to the
user.
You can get or set the modification time of a file or directory
with lastModified() and
setLastModified()
methods. The value is a long that
is the number of milliseconds since the epoch
(Jan 1, 1970, 00:00:00 GMT). We can also get the size of the file in
bytes with length().
Here’s a fragment of code that prints some information about a file:
FilefooFile=newFile("/tmp/boofa");Stringtype=fooFile.isFile()?"File ":"Directory ";Stringname=fooFile.getName();longlen=fooFile.length();System.out.println(type+name+", "+len+" bytes ");
If the File object
corresponds to a directory, we can list the files in the directory
with the list() method or the
listFiles()
method:
FiletmpDir=newFile("/tmp");String[]fileNames=tmpDir.list();File[]files=tmpDir.listFiles();
list() returns an array of
String objects that contains
filenames. listFiles() returns an
array of File objects. Note that in
neither case are the files guaranteed to be in any kind of order
(alphabetical, for example). You can use the Collections API to sort
strings alphabetically like so:
Listlist=Arrays.asList(sa);Collections.sort(list);
If the File refers to a
nonexistent directory, we can create the directory with mkdir() or mkdirs(). The
mkdir() method creates at most a
single directory level, so any intervening directories in the path
must already exist. mkdirs()
creates all directory levels necessary to create the full path of the
File specification. In either case,
if the directory cannot be created, the method returns false. Use renameTo() to rename
a file or directory and delete() to delete a
file or directory.
Although we can create a directory using the File object, this isn’t the most common way
to create a file; that’s normally done implicitly when we intend to
write data to it with a FileOutputStream or FileWriter, as we’ll discuss in a moment.
The exception is the createNewFile()
method, which can be used to attempt to create a new zero-length file
at the location pointed to by the File object. The useful thing about this
method is that the operation is guaranteed to be “atomic” with respect
to all other file creation in the filesystem. createNewFile() returns a Boolean value that
tells you whether the file was created or not. This is sometimes used
as a primitive locking feature—whoever creates the file first
“wins.” (The NIO package supports true file locks, as we’ll see
later.) This is useful in combination deleteOnExit(), which
flags the file to be automatically removed when the Java VM exits.
This combination allows you to guard resources or make an application
that can only be run in a single instance at a time. Another file
creation method that is related to the File class itself is the static method
createTempFile(), which creates a
file in a specified location using an automatically generated unique
name. This, too, is useful in combination with deleteOnExit().
The toURL() method
converts a file path to a file: URL
object. URLs are an abstraction that allows you to point to any kind
of object anywhere on the Net. Converting a File reference to a URL may be useful for
consistency with more general utilities that deal with URLs. See Chapter 14 for details. File URLs also come into
greater use with the NIO File API where they can be used to reference
new types of filesystems that are implemented directly in Java
code.
Table 12-1 summarizes the
methods provided by the File
class.
Table 12-1. File methods
Method | Return type | Description |
|---|---|---|
| Is the file executable? | |
| Is the file (or directory) readable? | |
| Is the file (or directory) writable? | |
| Creates a new file. | |
| Static method to create a new file, with the specified prefix and suffix, in the default temp file directory. | |
| Deletes the file (or directory). | |
| | When it exits, Java runtime system deletes the file. |
| Does the file (or directory) exist? | |
| Returns the absolute path of the file (or directory). | |
| Returns the absolute, case-correct path of the file (or directory). | |
| Get the number of bytes of unallocated space on the partition holding this path or 0 if the path is invalid. | |
| Returns the name of the file (or directory). | |
| Returns the name of the parent directory of the file (or directory). | |
| Returns the path of the file (or
directory). (Not to be confused with | |
| Get the size of the partition that contains the file path in bytes or 0 if the path is invalid. | |
| Get the number of bytes of user-accessible unallocated space on the partition holding this path or 0 if the path is invalid. This method attempts to take into account user write permissions. | |
| Is the filename (or directory name) absolute? | |
| Is the item a directory? | |
| Is the item a file? | |
| Is the item hidden? (System-dependent.) | |
| Returns the last modification time of the file (or directory). | |
| Returns the length of the file. | |
| Returns a list of files in the directory. | |
| Returns the contents of the
directory as an array of | |
| Returns array of root filesystems if any (e.g., C:/, D:/). | |
| Creates the directory. | |
| Creates all directories in the path. | |
| Renames the file (or directory). | |
| Sets execute permissions for the file. | |
| Sets the last-modified time of the file (or directory). | |
| Sets read permissions for the file. | |
| Sets the file to read-only status. | |
| Sets the write permissions for the file. | |
| Convert the File to an NIO File Path
(see the NIO File API). (Not to be confused with | |
|
OK, you’re probably sick of hearing about files already
and we haven’t even written a byte yet! Well, now the fun begins. Java
provides two fundamental streams for reading from and writing to files:
FileInputStream and
FileOutputStream. These
streams provide the basic byte-oriented InputStream and OutputStream functionality that is applied to
reading and writing files. They can be combined with the filter streams
described earlier to work with files in the same way as other stream
communications.
You can create a FileInputStream from a String pathname or a File object:
FileInputStreamin=newFileInputStream("/etc/passwd");
When you create a FileInputStream, the Java runtime system
attempts to open the specified file. Thus, the FileInputStream constructors can throw a
FileNotFoundException
if the specified file doesn’t exist or an IOException if some
other I/O error occurs. You must catch these exceptions in your code.
Wherever possible, it’s a good idea to get in the habit of using the new
Java 7 try-with-resources construct
to automatically close files for you when you are finished with
them:
try(FileInputStreamfin=newFileInputStream("/etc/passwd")){....// Fin will be closed automatically if needed upon exiting the try clause.}
When the stream is first created, its available() method and the File object’s length() method should return the same
value.
To read characters from a file as a Reader, you can wrap an InputStreamReader around a FileInputStream. If you want to use the
default character-encoding scheme for the platform, you can use the
FileReader class instead, which is
provided as a convenience. FileReader
is just a FileInputStream wrapped in
an InputStreamReader with some
defaults. For some crazy reason, you can’t specify a character encoding
for the FileReader to use, so it’s
probably best to ignore it and use InputStreamReader with FileInputStream.
The following class, ListIt ,
is a small utility that sends the contents of a file or directory to
standard output:
//file: ListIt.javaimportjava.io.*;classListIt{publicstaticvoidmain(Stringargs[])throwsException{Filefile=newFile(args[0]);if(!file.exists()||!file.canRead()){System.out.println("Can't read "+file);return;}if(file.isDirectory()){String[]files=file.list();for(Stringfile:files)System.out.println(file);}elsetry{Readerir=newInputStreamReader(newFileInputStream(file));BufferedReaderin=newBufferedReader(ir);Stringline;while((line=in.readLine())!=null)System.out.println(line);}catch(FileNotFoundExceptione){System.out.println("File Disappeared");}}}
ListIt constructs a File object from its first command-line
argument and tests the File to see
whether it exists and is readable. If the File is a directory, ListIt outputs the names of the files in the
directory. Otherwise, ListIt reads
and outputs the file, line by line.
For writing files, you can create a FileOutputStream from a String pathname or a File object. Unlike FileInputStream, however, the FileOutputStream constructors don’t throw a
FileNotFoundException. If the
specified file doesn’t exist, the FileOutputStream creates the file. The
FileOutputStream constructors can
throw an IOException if some other
I/O error occurs, so you still need to handle this exception.
If the specified file does exist, the FileOutputStream opens it for writing. When
you subsequently call the write()
method, the new data overwrites the current contents of the file. If you
need to append data to an existing file, you can use a form of the
constructor that accepts a Boolean append flag:
FileInputStreamfooOut=newFileOutputStream(fooFile);// overwrite fooFileFileInputStreampwdOut=newFileOutputStream("/etc/passwd",true);// append
Another way to append data to files is with RandomAccessFile, which we’ll discuss
shortly.
Just as with reading, to write characters (instead of bytes) to a
file, you can wrap an OutputStreamWriter
around a FileOutputStream. If you
want to use the default character-encoding scheme, you can use the
FileWriter class instead, which is
provided as a convenience.
The following example reads a line of data from standard input and writes it to the file /tmp/foo.txt:
Strings=newBufferedReader(newInputStreamReader(System.in)).readLine();Fileout=newFile("/tmp/foo.txt");FileWriterfw=newFileWriter(out);PrintWriterpw=newPrintWriter(fw)pw.println(s);pw.close();
Notice how we wrapped the FileWriter in a PrintWriter to facilitate writing the data.
Also, to be a good filesystem citizen, we called the close() method when we’re done with the
FileWriter. Here, closing the
PrintWriter closes the underlying
Writer for us. We also could have
used try-with-resources
here.
The java.io.RandomAccessFile class provides the
ability to read and write data at a specified location in a file.
RandomAccessFile implements both the
DataInput and DataOutput interfaces, so you can use it to
read and write strings and primitive types at locations in the file just
as if it were a DataInputStream and
DataOutputStream. However, because
the class provides random, rather than sequential, access to file data,
it’s not a subclass of either InputStream or OutputStream.
You can create a RandomAccessFile from a String pathname or a File object. The constructor also takes a
second String argument that specifies
the mode of the file. Use the string r for a read-only file or rw for a read/write file.
try{RandomAccessFileusers=newRandomAccessFile("Users","rw")}catch(IOExceptione){...}
When you create a RandomAccessFile in read-only mode, Java tries
to open the specified file. If the file doesn’t exist, RandomAccessFile throws an IOException. If,
however, you’re creating a RandomAccessFile in read/write mode, the
object creates the file if it doesn’t exist. The constructor can still
throw an IOException if another I/O
error occurs, so you still need to handle this exception.
After you have created a RandomAccessFile, call any of the normal
reading and writing methods, just as you would with a DataInputStream or DataOutputStream. If you try to write to a
read-only file, the write method throws an IOException.
What makes a RandomAccessFile
special is the seek() method. This
method takes a long value and uses it
to set the byte offset location for reading and writing in the file. You
can use the getFilePointer() method
to get the current location. If you need to append data to the end of
the file, use length() to determine
that location, then seek() to it. You
can write or seek beyond the end of a file, but you can’t read beyond
the end of a file. The read() method
throws an EOFException if you try
to do this.
Here’s an example of writing data for a simplistic database:
users.seek(userNum*RECORDSIZE);users.writeUTF(userName);users.writeInt(userID);...
In this naive example, we assume that the String length for userName, along with any data that comes after
it, fits within the specified record size.
A big part of packaging and deploying an application is
dealing with all of the resource files that must go with it, such as
configuration files, graphics, and application data. Java provides
several ways to access these resources. One way is to simply open files
and read the bytes. Another is to construct a URL pointing to a
well-known location in the filesystem or over the network. (We’ll
discuss working with URLs in detail in Chapter 14.) The problem with these methods is that
they generally rely on knowledge of the application’s location and
packaging, which could change or break if it is moved. What is really
needed is a universal way to access resources associated with our
application, regardless of how it’s installed. The Class class’s getResource() method
and the Java classpath provides just this. For example:
URLresource=MyApplication.class.getResource("/config/config.xml");
Instead of constructing a File
reference to an absolute file path, or relying on composing information
about an install directory, the getResource() method provides a standard way
to get resources relative to the classpath of the application. A
resource can be located either relative to a given class file or to the
overall system classpath. getResource() uses the classloader that loads
the application’s class files to load the data. This means that no
matter where the application classes reside—a web server, the local
filesystem, or even inside a JAR file or other archive—we can load
resources packaged with those classes consistently.
Although we haven’t discussed URLs yet, we can tell you that many
APIs for loading data (for example, images) accept a URL directly. If
you’re reading the data yourself, you can ask the URL for an InputStream with the URL openStream() method and treat it like any
other stream. A convenience method called getResourceAsStream()
skips this step for you and returns an InputStream directly.
getResource() takes as an
argument a slash-separated resource path for the
resource and returns a URL. There are two kinds of resource paths:
absolute and relative. An absolute path begins with a slash (for
example, /config/config.xml). In this case, the
search for the object begins at the “top” of the classpath. By the “top”
of the classpath, we mean that Java looks within each element of the
classpath (directory or JAR file) for the specified file. Given
/config/config.xml, it would check each directory
or JAR file in the path for the file
config/config.xml. In this case, the class on which
getResource() is called doesn’t
matter as long as it’s from a class loader that has the resource file in
its classpath. For example:
URLdata=AnyClass.getResource("/config/config.xml");
On the other hand, a relative URL does not begin with a slash (for
example, mydata.txt). In this case, the search
begins at the location of the class file on which getResource() is called. In other words, the
path is relative to the package of the target class file. For example,
if the class file foo.bar.MyClass is located at the
path foo/bar/MyClass.class in some directory or JAR
of the classpath and the file mydata.txt is in the
same directory (foo/bar/mydata.txt), we can request
the file via MyClass with:
URLdata=MyClass.getResource("mydata.txt");
In this case, the class and file come from the same logical directory. We say logical because the search is not limited to the classpath element from which the class was loaded. Instead, the same relative path is searched in each element of the classpath—just as with an absolute path—until it is found. Although we’d expect the file mydata.txt to be packaged physically with MyClass.class, it might be found in another JAR file or directory at the same relative and corresponding location.
For example, here’s an application that looks up some resources:
packagemypackage;importjava.net.URL;importjava.io.IOException;publicclassFindResources{publicstaticvoidmain(String[]args)throwsIOException{// absolute from the classpathURLurl=FindResources.class.getResource("/mypackage/foo.txt");// relative to the class locationurl=FindResources.class.getResource("foo.txt");// another relative documenturl=FindResources.class.getResource("docs/bar.txt");}}
The FindResources class belongs
to the mypackage package, so its
class file will live in a mypackage directory
somewhere on the classpath. FindResources locates the document
foo.txt using an absolute and then a relative URL.
At the end, FindResources uses a
relative path to reach a document in the
mypackage/docs directory. In each case, we refer to
the FindResources’s Class object using the static .class notation. Alternatively, if we had an
instance of the object, we could use its getClass() method to
reach the Class object.
Again, getResource() returns a
URL for whatever type of object you reference. This could be a text file
or properties file that you want to read as a stream, or it might be an
image or sound file or some other object. You can open a stream to the
URL to parse the data yourself or hand the URL over to an API that deals
with URLs. We discuss URLs in depth in Chapter 14. We should also emphasize that loading
resources in this way completely shields your application from the
details of how it is packaged or deployed. You may start with your
application in loose files and then package it into a JAR file and the
resources will still be loaded. Java applets (discussed in a later
chapter) may even load files in this way over the network because the
applet class loader treats the server as part of its
classpath.