Apache Commons IO Best Practices

This article lists a large number of “best practices” for the Java input/output area (IO area).

java.io.File

Usually when you need to deal with files or filenames, there are many situations that can go wrong:

• A class can run on Unix but cannot run on Windows, and vice versa.
• Invalid filenames due to double path separators (path separator) or missing path separators (path separator).
• UNC (UNC) filenames (on Windows) that conform to the Universal Naming Convention cannot work in developers’ home-grown (home-grown) utility methods
• and so on

The above are the exact reasons why string (String) filenames do not work. Using the java.io.File class to handle the above situations would be more appropriate. Therefore our best practice (best practice) recommends using the java.io.File class instead of strings (String) to handle filenames to avoid depending on a specific platform (platform).

Commons-io 1.1 includes a class dedicated to handling filenames—the filename utility class (FilenameUtils). It handles many of the above filename problems, but we still recommend that you use java.io.File objects as much as possible.

Let’s look at an example.

public static String getExtension(String filename) {
   int index = filename.lastIndexOf('.');
   if (index == -1) {
     return "";
   } else {
     return filename.substring(index + 1);
   }
 }

Simple, right? Yes, but what happens if a developer passes (pass) a full path (full path) string rather than just a filename? Consider the following case, passing a perfectly valid path: "C:\Temp\documentation.new\README". The method (method) defined above might return (return) "new\README"—completely not the result you wanted.

Please use java.io.File instead of strings (String) to handle filenames. The functionality provided by this class is well tested (well tested). In the file utility class (FileUtils) you will find other useful utility methods (function) related to java.io.File.

For example:

String tmpdir = "/var/tmp";
 String tmpfile = tmpdir System.getProperty("file.separator") "test.tmp";
 InputStream in = new java.io.FileInputStream(tmpfile);

Change to:

File tmpdir = new File("/var/tmp");
 File tmpfile = new File(tmpdir, "test.tmp");
 InputStream in = new java.io.FileInputStream(tmpfile);

Input/Output Stream Buffering (Buffering streams)

Input/output performance depends heavily on the buffering strategy (buffering strategy). Generally speaking, buffering 512 or 1024 bytes in size to read data blocks (packets) is very fast, because this size matches very well with the size of data blocks (packets) in the hard disk (harddisk) file system (file system) or file cache (file system cache). And when you only read a few bytes, time performance will drop significantly (drop).

When reading or writing input/output streams, especially when accessing files, make sure you correctly buffer the input/output streams. You only need to use a buffered byte input stream (BufferedInputStream) to decorate (decorate) your file byte input stream (FileInputStream)

Translator’s note: Java’s input/output streams use the 修饰模式, also known as the 装饰模式:

InputStream in = new java.io.FileInputStream(myfile);
 try {
   in = new java.io.BufferedInputStream(in);
   
   in.read(.....
 } finally {
   IOUtils.closeQuietly(in);
 }

Note that you cannot cache an already buffered input/output stream. Some components, for example XML parsers (XML parser), will use their own byte input stream (InputStream) cache decoration (decorate). Passing a cached input/output stream to an XML parser (XML parser) does not have much effect but will slow down (slow down) your code performance. If you use our copy utility class (CopyUtils) or input/output utility class (IOUtils), you do not need to additionally buffer the input/output streams; treat this code as already buffered during the copy process. Check the Javadoc for more information. Other cases, such as when you write a byte array output stream (ByteArrayOutputStream) to memory (memory), do not require buffering.

This article is published with authorization from Hou Junxiong. Translation: Hou Junxiong (QQ: 2442278700) Blog: http://blog.csdn.net/houjx114