Re: Enhancement request
Martin Gregorie wrote:
File inf = new File ("myinputfile.txt");
InputStream is = new FileInputStream(inf);
Reader isr = new InputStreamReader(is);
BufferedReader inb = new BufferedReader(isr);
is just plain perverse. When I can release all the resources with
It isn't too hard, although I agree it takes getting use to. It always
follows the pattern:
Reader( StreamReader( Stream ) )
And same with Writers/StreamWriter.
The reason is Streams are older, and didn't quite work out. So Sun
needed to add Readers and Writers to fix the problem. But to get
backwards compatibility, they didn't touch the old Streams. The added
"bridge" classes instead: StreamReader and StreamWriter.
So those classes always go in between the Reader/Writer and the Stream,
and the Stream is always the deepest nested.
inb.close()
why can't I acquire them with
BufferedReader inb = new BufferedReader(inf);
or
BufferedReader("myinputfile.txt");
Maybe there's a good reason for this, but I'm damned if I can see it.
This might be a good job for a utility class with some static methods:
public class IOUtil {
private IOUtil() {} // only static methods, can't instantiate
public static BufferedReader makeReader( String s ) {
return new BufferedReader( new InputStreamReader( new
FileInputStream( s ) ) );
}
public static BufferedReader makeReader( File f ) {
return new BufferedReader( new InputStreamReader(
new FileInputStream( f ) ) );
}
}
etc. Tedious but do-able, and you only have to do it once. I'm not
sure if this could be improved with generic methods or covariant return
types.