10.7 Java 1.1的IO流
到这个时候,大家或许会陷入一种困境之中,怀疑是否存在IO流的另一种设计方案,并可能要求更大的代码量。还有人能提出一种更古怪的设计吗?事实上,Java 1.1对IO流库进行了一些重大的改进。看到Reader和Writer类时,大多数人的第一个印象(就象我一样)就是它们用来替换原来的InputStream和OutputStream类。但实情并非如此。尽管不建议使用原始数据流库的某些功能(如使用它们,会从编译器收到一条警告消息),但原来的数据流依然得到了保留,以便维持向后兼容,而且:
(1) 在老式层次结构里加入了新类,所以Sun公司明显不会放弃老式数据流。
(2) 在许多情况下,我们需要与新结构中的类联合使用老结构中的类。为达到这个目的,需要使用一些“桥”类:
InputStreamReader将一个InputStream转换成Reader,OutputStreamWriter将一个OutputStream转换成Writer。 所以与原来的IO流库相比,经常都要对新IO流进行层次更多的封装。同样地,这也属于装饰器方案的一个缺点——需要为额外的灵活性付出代价。
之所以在Java 1.1里添加了Reader和Writer层次,最重要的原因便是国际化的需求。老式IO流层次结构只支持8位字节流,不能很好地控制16位Unicode字符。由于Unicode主要面向的是国际化支持(Java内含的char是16位的Unicode),所以添加了Reader和Writer层次,以提供对所有IO操作中的Unicode的支持。除此之外,新库也对速度进行了优化,可比旧库更快地运行。 与本书其他地方一样,我会试着提供对类的一个概述,但假定你会利用联机文档搞定所有的细节,比如方法的详尽列表等。
10.7.1 数据的发起与接收
Java 1.0的几乎所有IO流类都有对应的Java 1.1类,用于提供内建的Unicode管理。似乎最容易的事情就是“全部使用新类,再也不要用旧的”,但实际情况并没有这么简单。有些时候,由于受到库设计的一些限制,我们不得不使用Java 1.0的IO流类。特别要指出的是,在旧流库的基础上新加了java.util.zip库,它们依赖旧的流组件。所以最明智的做法是“尝试性”地使用Reader和Writer类。若代码不能通过编译,便知道必须换回老式库。
下面这张表格分旧库与新库分别总结了信息发起与接收之间的对应关系。
Stream | Reader/Writer |
---|---|
InputStream | InputStreamReader |
OutputStream | OutputStreamWriter |
FileInputStream | FileReader |
FileOutputStream | FileWriter |
StringBufferInputStream | StringReader |
(no corresponding class) | StringWriter |
ByteArrayInputStream | CharArrayReader |
ByteArrayOutputStream | CharArrayWriter |
PipedInputStream | PipedReader |
PipedOutputStream | PipedWriter |
我们发现即使不完全一致,但旧库组件中的接口与新接口通常也是类似的。
10.7.2 修改数据流的行为
在Java 1.0中,数据流通过FilterInputStream和FilterOutputStream的“装饰器”(Decorator)子类适应特定的需求。Java 1.1的IO流沿用了这一思想,但没有继续采用所有装饰器都从相同“filter”(过滤器)基础类中衍生这一做法。若通过观察类的层次结构来理解它,这可能令人出现少许的困惑。
在下面这张表格中,对应关系比上一张表要粗糙一些。之所以会出现这个差别,是由类的组织造成的:尽管BufferedOutputStream是FilterOutputStream的一个子类,但是BufferedWriter并不是FilterWriter的子类(对后者来说,尽管它是一个抽象类,但没有自己的子类或者近似子类的东西,也没有一个“占位符”可用,所以不必费心地寻找)。然而,两个类的接口是非常相似的,而且不管在什么情况下,显然应该尽可能地使用新版本,而不应考虑旧版本(也就是说,除非在一些类中必须生成一个Stream,不可生成Reader或者Writer)。
过滤器:Java 1.0类 | 对应的Java 1.1类 |
---|---|
FilterInputStream | FilterReader |
FilterOutputStream | FilterWriter(没有子类的抽象类) |
BufferedInputStream | BufferedReader(也有readLine()) |
BufferedOutputStream | BufferedWriter |
DataInputStream | 使用DataInputStream(除非要使用readLine(),那时需要使用一个BufferedReader) |
PrintStream | PrintWriter |
LineNumberInputStream | LineNumberReader |
StreamTokenizer | StreamTokenizer(用构建器取代Reader) |
PushBackInputStream | PushBackReader |
有一条规律是显然的:若想使用readLine(),就不要再用一个DataInputStream来实现(否则会在编译期得到一条出错消息),而应使用一个BufferedReader。但除这种情况以外,DataInputStream仍是Java 1.1 IO库的“首选”成员。
为了将向PrintWriter的过渡变得更加自然,它提供了能采用任何OutputStream对象的构建器。PrintWriter提供的格式化支持没有PrintStream那么多;但接口几乎是相同的。
10.7.3 未改变的类
显然,Java库的设计人员觉得以前的一些类毫无问题,所以没有对它们作任何修改,可象以前那样继续使用它们:
没有对应Java 1.1类的Java 1.0类 |
---|
DataOutputStream |
File |
RandomAccessFile |
SequenceInputStream |
特别未加改动的是DataOutputStream,所以为了用一种可转移的格式保存和获取数据,必须沿用InputStream和OutputStream层次结构。
10.7.4 一个例子
为体验新类的效果,下面让我们看看如何修改IOStreamDemo.java示例的相应区域,以便使用Reader和Writer类:
//: NewIODemo.java
// Java 1.1 IO typical usage
import java.io.*;
public class NewIODemo {
public static void main(String[] args) {
try {
// 1. Reading input by lines:
BufferedReader in =
new BufferedReader(
new FileReader(args[0]));
String s, s2 = new String();
while((s = in.readLine())!= null)
s2 += s + "\n";
in.close();
// 1b. Reading standard input:
BufferedReader stdin =
new BufferedReader(
new InputStreamReader(System.in));
System.out.print("Enter a line:");
System.out.println(stdin.readLine());
// 2. Input from memory
StringReader in2 = new StringReader(s2);
int c;
while((c = in2.read()) != -1)
System.out.print((char)c);
// 3. Formatted memory input
try {
DataInputStream in3 =
new DataInputStream(
// Oops: must use deprecated class:
new StringBufferInputStream(s2));
while(true)
System.out.print((char)in3.readByte());
} catch(EOFException e) {
System.out.println("End of stream");
}
// 4. Line numbering & file output
try {
LineNumberReader li =
new LineNumberReader(
new StringReader(s2));
BufferedReader in4 =
new BufferedReader(li);
PrintWriter out1 =
new PrintWriter(
new BufferedWriter(
new FileWriter("IODemo.out")));
while((s = in4.readLine()) != null )
out1.println(
"Line " + li.getLineNumber() + s);
out1.close();
} catch(EOFException e) {
System.out.println("End of stream");
}
// 5. Storing & recovering data
try {
DataOutputStream out2 =
new DataOutputStream(
new BufferedOutputStream(
new FileOutputStream("Data.txt")));
out2.writeDouble(3.14159);
out2.writeBytes("That was pi");
out2.close();
DataInputStream in5 =
new DataInputStream(
new BufferedInputStream(
new FileInputStream("Data.txt")));
BufferedReader in5br =
new BufferedReader(
new InputStreamReader(in5));
// Must use DataInputStream for data:
System.out.println(in5.readDouble());
// Can now use the "proper" readLine():
System.out.println(in5br.readLine());
} catch(EOFException e) {
System.out.println("End of stream");
}
// 6. Reading and writing random access
// files is the same as before.
// (not repeated here)
} catch(FileNotFoundException e) {
System.out.println(
"File Not Found:" + args[1]);
} catch(IOException e) {
System.out.println("IO Exception");
}
}
} ///:~
大家一般看见的是转换过程非常直观,代码看起来也颇相似。但这些都不是重要的区别。最重要的是,由于随机访问文件已经改变,所以第6节未再重复。
第1节收缩了一点儿,因为假如要做的全部事情就是读取行输入,那么只需要将一个FileReader封装到BufferedReader之内即可。第1b节展示了封装System.in,以便读取控制台输入的新方法。这里的代码量增多了一些,因为System.in是一个DataInputStream,而且BufferedReader需要一个Reader参数,所以要用InputStreamReader来进行转换。
在2节,可以看到如果有一个字串,而且想从中读取数据,只需用一个StringReader替换StringBufferInputStream,剩下的代码是完全相同的。
第3节揭示了新IO流库设计中的一个错误。如果有一个字串,而且想从中读取数据,那么不能再以任何形式使用StringBufferInputStream。若编译一个涉及StringBufferInputStream的代码,会得到一条“反对”消息,告诉我们不要用它。此时最好换用一个StringReader。但是,假如要象第3节这样进行格式化的内存输入,就必须使用DataInputStream——没有什么“DataReader”可以代替它——而DataInputStream很不幸地要求用到一个InputStream参数。所以我们没有选择的余地,只好使用编译器不赞成的StringBufferInputStream类。编译器同样会发出反对信息,但我们对此束手无策(注释②)。 StringReader替换StringBufferInputStream,剩下的代码是完全相同的。
②:到你现在正式使用的时候,这个错误可能已经修正。
第4节明显是从老式数据流到新数据流的一个直接转换,没有需要特别指出的。在第5节中,我们被强迫使用所有的老式数据流,因为DataOutputStream和DataInputStream要求用到它们,而且没有可供替换的东西。然而,编译期间不会产生任何“反对”信息。若不赞成一种数据流,通常是由于它的构建器产生了一条反对消息,禁止我们使用整个类。但在DataInputStream的情况下,只有readLine()是不赞成使用的,因为我们最好为readLine()使用一个BufferedReader(但为其他所有格式化输入都使用一个DataInputStream)。
若比较第5节和IOStreamDemo.java中的那一小节,会注意到在这个版本中,数据是在文本之前写入的。那是由于Java 1.1本身存在一个错误,如下述代码所示:
//: IOBug.java
// Java 1.1 (and higher?) IO Bug
import java.io.*;
public class IOBug {
public static void main(String[] args)
throws Exception {
DataOutputStream out =
new DataOutputStream(
new BufferedOutputStream(
new FileOutputStream("Data.txt")));
out.writeDouble(3.14159);
out.writeBytes("That was the value of pi\n");
out.writeBytes("This is pi/2:\n");
out.writeDouble(3.14159/2);
out.close();
DataInputStream in =
new DataInputStream(
new BufferedInputStream(
new FileInputStream("Data.txt")));
BufferedReader inbr =
new BufferedReader(
new InputStreamReader(in));
// The doubles written BEFORE the line of text
// read back correctly:
System.out.println(in.readDouble());
// Read the lines of text:
System.out.println(inbr.readLine());
System.out.println(inbr.readLine());
// Trying to read the doubles after the line
// produces an end-of-file exception:
System.out.println(in.readDouble());
}
} ///:~
看起来,我们在对一个writeBytes()的调用之后写入的任何东西都不是能够恢复的。这是一个十分有限的错误,希望在你读到本书的时候已获得改正。为检测是否改正,请运行上述程序。若没有得到一个违例,而且值都能正确打印出来,就表明已经改正。
10.7.5 重导向标准IO
Java 1.1在System类中添加了特殊的方法,允许我们重新定向标准输入、输出以及错误IO流。此时要用到下述简单的静态方法调用:
setIn(InputStream)
setOut(PrintStream)
setErr(PrintStream)
如果突然要在屏幕上生成大量输出,而且滚动的速度快于人们的阅读速度,输出的重定向就显得特别有用。在一个命令行程序中,如果想重复测试一个特定的用户输入序列,输入的重定向也显得特别有价值。下面这个简单的例子展示了这些方法的使用:
//: Redirecting.java
// Demonstrates the use of redirection for
// standard IO in Java 1.1
import java.io.*;
class Redirecting {
public static void main(String[] args) {
try {
BufferedInputStream in =
new BufferedInputStream(
new FileInputStream(
"Redirecting.java"));
// Produces deprecation message:
PrintStream out =
new PrintStream(
new BufferedOutputStream(
new FileOutputStream("test.out")));
System.setIn(in);
System.setOut(out);
System.setErr(out);
BufferedReader br =
new BufferedReader(
new InputStreamReader(System.in));
String s;
while((s = br.readLine()) != null)
System.out.println(s);
out.close(); // Remember this!
} catch(IOException e) {
e.printStackTrace();
}
}
} ///:~
这个程序的作用是将标准输入同一个文件连接起来,并将标准输出和错误重定向至另一个文件。 这是不可避免会遇到“反对”消息的另一个例子。用-deprecation标志编译时得到的消息如下:
注意:不推荐使用构建器java.io.PrintStream(java.io.OutputStream)。
然而,无论System.setOut()还是System.setErr()都要求用一个PrintStream作为参数使用,所以必须调用PrintStream构建器。所以大家可能会觉得奇怪,既然Java 1.1通过反对构建器而反对了整个PrintStream,为什么库的设计人员在添加这个反对的同时,依然为System添加了新方法,且指明要求用PrintStream,而不是用PrintWriter呢?毕竟,后者是一个崭新和首选的替换措施呀?这真令人费解。