Files

Working with files in Java is easy but poses some conceptual problems. In the real world, the host filesystem lies outside of Java's virtual environment, and can, therefore, still suffer from architecture and implementation differences. Java tries to mask some of these differences by providing information to help an app tailor itself to the local environment; we'll mention these areas as they come up. Later, we'll show you how to avoid these issues for read-only app files and resources by using the Java classpath to insulate you from the filesystem entirely.

The java.io.File Class

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 specialized streams for that purpose.

File constructors

You can create an instance of File from a String pathname:

 File fooFile = new File( "/tmp/foo.txt" );
 File barDir = new File( "/tmp/bar" );

You can also create a file with a relative path:

 File f = new File( "foo" );

In this case, Java works relative to the current working directory of the Java interpreter. You can determine the current working directory by checking 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:

 File fooFile = new File( "/tmp", "foo.txt" );

With yet another variation, you can specify the directory with a File object and the filename with a String:

 File tmpDir = new File( "/tmp" ); // File for directory /tmp
 File fooFile = new File ( tmpDir, "foo.txt" );

None of these File constructors actually creates a file or directory, and it isn't 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.

Path localization

One of the reasons that working with files in Java is problematic is that pathnames are expected to follow the conventions of the local filesystem. The main differences are that the Windows filesystem uses "roots" or drive letters (for example, C:) and the backslash (\) instead of the forward slash (/) path separator. On some systems, Java tries to compensate for the differences. For example, in the current implementation on Windows platforms, Java accepts paths with either forward slashes or backslashes. However, under Solaris, Java accepts only paths with forward slashes. Your best bet is to make sure you follow the filename conventions of the host filesystem. If your app 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 app 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 you use internally, for instance the forward slash (/), and do a String replace to substitute for the localized separator character:

 // we'll use forward slash as our standard
 String path = "mail/2004/june/merle";
 path = path.replace('/', File.separatorChar);
 File mailbox = new File( 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" };
 StringBuffer sb = new StringBuffer(path[0]);
 for (int i=1; i< path.length; i++)
 sb.append( File.separator + path[i] );
 File mailbox = new File( sb.toString( ) );

One thing to remember is that Java interprets the backslash character (\) 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 app, a graphical file chooser dialogue shields you from this problem entirely.

File operations

Once we have a File object, we can use it to ask for information about the file or directory and to perform standard operations on it. A number of methods let us ask questions about the File. For example, isFile( ) returns true if the File represents a 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 app's working directory or any concept of a working root or drive. 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; getPath( ) returns the directory information without the filename. If the File has an absolute path specification, getAbsolutePath( ) returns that path. Otherwise, it returns the relative path appended to the current working directory. getParent( ) returns the parent directory of the File. 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 using the method getCanonicalPath( ). In Windows, for example, you can create a File object whose getAbsolutePath( ) is C:\Autoexec.bat but whose getCanonical-Path( ) is C:\AUTOEXEC.BAT, both actually pointing 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:

 File fooFile = new File( "/tmp/boofa" );
 String type = fooFile.isFile( ) ? "File " : "Directory ";
 String name = fooFile.getName( );
 long len = 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:

 File tmpDir = new File("/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:

 List list = Arrays.asList( sa );
 Collections.sort(l);

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 featurewhoever creates the file first "wins." (The NIO package supports true file locks, as we'll see later). This is useful in combination with deleteOnExit( ), which flags the file to be automatically removed when the Java VM exits. Another file creation method 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 for details. Table 12-1 summarizes the methods provided by the File class.

Table 12-1. File methods

File Streams

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 specialized streams for reading from and writing to files: FileInputStream and FileOutputStream. These streams provide the basic InputStream and OutputStream functionality 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:

 FileInputStream in = new FileInputStream( "/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. When the stream is first created, its available( ) method and the File object's length( ) method should return the same value. To save resources, you can call the close( ) method when you are done with the file. 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 works just like FileInputStream, except that it is a character stream. (For some crazy reason, you can't specify a character encoding for the FileReader to use, so keep the InputStreamReader in mind.) The following class, ListIt, is a small utility that sends the contents of a file or directory to standard output:

 //file: ListIt.java
 import java.io.*;
 class ListIt {
 public static void main ( String args[] ) throws Exception {
 File file = new File( args[0] );
 if ( !file.exists( ) || !file.canRead( ) ) {
 System.out.println( "Can't read " + file );
 return;
 }
 if ( file.isDirectory( ) ) {
 String [] files = file.list( );
 for ( String file : files )
 System.out.println( file );
 } else
 try {
 FileReader fr = new FileReader ( file );
 BufferedReader in = new BufferedReader( fr );
 String line;
 while ((line = in.readLine( )) != null)
 System.out.println(line);
 }
 catch ( FileNotFoundException e ) {
 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:

 FileInputStream fooOut =
 new FileOutputStream( fooFile ); // overwrite fooFile
 FileInputStream pwdOut =
 new FileOutputStream( "/etc/passwd", true ); // append

Another way to append data to files is with RandomAccessFile, as 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 instead the FileWriter class, 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:

 String s = new BufferedReader(
 new InputStreamReader( System.in ) ).readLine( );
 File out = new File( "/tmp/foo.txt" );
 FileWriter fw = new FileWriter ( out );
 PrintWriter pw = new PrintWriter( fw )
 pw.println( s );
 fw.close( );

Notice how we wrapped the FileWriter in a PrintWriter to facilitate writing the data. Also, to be a good filesystem citizen, we've called the close( ) method when we're done with the FileWriter.

RandomAccessFile

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 r for a read-only file or rw for a read/write file. Here's how we would start to create a simple database to keep track of user information:

 try {
 RandomAccessFile users =
 new RandomAccessFile( "Users", "rw" )
 } catch (IOException e) { ... }

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 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 some data to our user database:

 users.seek( userNum * RECORDSIZE );
 users.writeUTF( userName );
 users.writeInt( userID );

Of course, 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.

Applets and Files

Unless otherwise restricted, a Java app can read and write to the host filesystem with the same level of access as the user running the Java interpreter. For security reasons, untrusted applets and apps are not generally permitted to read from or write to arbitrary places in the filesystem. The ability of untrusted code to read and write files, as with any kind of system resource, is under the control of the system security policy, through a SecurityManager object. A security policy is set by the app that is running the untrusted code, such as appletviewer or a Java-enabled web browser. All filesystem access must first pass the scrutiny of the SecurityManager. Most web browsers do not allow untrusted applets any access to the filesystem. However, as we'll see in , signed applets can be given arbitrary access to the filesystem, just like a standalone Java app. Currently, the only way for a filesystem-restricted Java program to save any real amount of data is through talking to its server via HTTP, or other network protocols. In , we'll take a detailed look at building networked apps with sockets. With the tools described in that chapter, it's possible to build powerful client/server apps.^[*] A big part of packaging and deploying an app is dealing with all of the resource files that must go with it, such as configuration files, graphics, and app 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 .) The problem with these methods is that they generally rely on knowledge of the app'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 app, regardless of how it's installed. The Class class's geTResource( ) method and the Java classpath provides just this. For example:

^[*] At one point, Sun introduced a Java extension called WebNFS, which allows applets and apps to work with files on an NFS server in much the same way as the ordinary File API. But this never took off.

 URL resource = Myapp.class.getResource("/config/config.xml");

Instead of constructing a File reference or URL pointing 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. A resource can be located either relative to a given class file or to the system classpath. geTResource( ) uses the classloader that loads the app's class files to load the data. This means that no matter where the app classes residea web server, the local filesystem, or even inside a JAR file or other archivewe can load resources packaged with them 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, it doesn't matter on which class getresource( ) is called as long as it's from a classloader which has the resource file in its classpath. For example:

 URL data = AnyClass.getResource("/config/config.xml");

A relative URL, on the other hand, does not begin with a slash (for example, simply 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 element 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:

 URL data = 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 only 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 corresponding location. For example, here's an app that looks up some resources:

 //file: FindResources.java
 package mypackage;
 import java.net.URL;
 import java.io.IOException; public class FindResources {
 public static void main( String [] args ) throws IOException {
 // absolute from the classpath
 URL url = FindResources.class.getResource("/mypackage/foo.txt");
 // relative to the class location
 url = FindResources.class.getResource("foo.txt");
 // another relative document
 url = 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. For an applet, the search is similar but occurs on the host from which the applet was loaded. getresource( ) first checks any JAR files loaded with the applet and then searches the normal remote applet classpath, constructed relative to the applet's codebase URL. 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 . We should also emphasize that loading resources in this way completely shields your app from the details of how it is packaged or deployed. You may start with your app in loose files and then package it into a JAR file and the resources will still be loaded. Applets may even load files in this way over the network since the applet classloader treats the server as part of its classpath.

• Previous
• Next