Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
how java io chain works?
- Thread starter kanghao
- Start date
sedj
Programmer
- Aug 6, 2002
- 5,610
Whats "java io chain" ?
Click here to learn Ways to help with Tsunami Relief
--------------------------------------------------
Free Database Connection Pooling Software
Click here to learn Ways to help with Tsunami Relief
--------------------------------------------------
Free Database Connection Pooling Software
- Thread starter
- #3
FileOutputStream file = new FileOutputStream("myobject.ser");
BufferedOutputStream bout = new BufferedOutputStream(file);
ObjectOutputStream out = new ObjectOutputStream(bout);
FileOutputStream - BufferedOutputStream - ObjectOutputStream
...
make sense?
BufferedOutputStream bout = new BufferedOutputStream(file);
ObjectOutputStream out = new ObjectOutputStream(bout);
FileOutputStream - BufferedOutputStream - ObjectOutputStream
...
make sense?
sedj
Programmer
- Aug 6, 2002
- 5,610
Well I'm not really sure what you mean by "memorize" them ... personally I know most of the IO streams without requiring to look up the API documentation, but then I've been programming Java for three and a half years. But certainly, the compiler does not care if you know the IO streams by heart or not !
A couple of points though - ObjectOutputStream is only used if you need to serialize an actual object to a file, or maybe socket - there are no onther times when you should use it. Also, in that "chain" as you put it, I would write it like this instead :
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("myobject.ser"));
Click here to learn Ways to help with Tsunami Relief
--------------------------------------------------
Free Database Connection Pooling Software
A couple of points though - ObjectOutputStream is only used if you need to serialize an actual object to a file, or maybe socket - there are no onther times when you should use it. Also, in that "chain" as you put it, I would write it like this instead :
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("myobject.ser"));
Click here to learn Ways to help with Tsunami Relief
--------------------------------------------------
Free Database Connection Pooling Software
Just point out that the "chain" is not universal. I mean that every stream object has a meaning, and the "chain" may be different depending on what you're trying to do.
For example, I normaly use BufferedReader because of performance issues, but there are times where I don't want to buffer the data I'm reading.
My advice is that you take a look at the documentation of the API and read the description of each reader, at least the ones you're using. That will make things a lot easier.
Cheers,
Dian
For example, I normaly use BufferedReader because of performance issues, but there are times where I don't want to buffer the data I'm reading.
My advice is that you take a look at the documentation of the API and read the description of each reader, at least the ones you're using. That will make things a lot easier.
Cheers,
Dian
The pattern that allows you to "chain" them is fairly simple and elloquent. The way it works is that you can stack streams to get specialized streams that do a lot of stuff with few amounts of calls, by adding another layer. For instance:
Compression, Encryption, Object, Buffer, Socket ...
And order doesn't matter, in that you can put them in more or less any order that is needed by your application (but make sure your doing what you want, and that your doing them in the right order when doing the oppisite direction).
If I encrypt, compress, write to file .. then on the way out I need to read from file, decompress and then decrypt (oppisite order).
It's good to know the ones you use a lot... But being a good programmer has less to do with memorizing libraries and more to do with knowing where to get good answers quickly. In general, you don't want to read all the documentation ever written on every language before writing a line of code, but rather to write a lot of code and know where to look things up when you get stuck.
Compression, Encryption, Object, Buffer, Socket ...
And order doesn't matter, in that you can put them in more or less any order that is needed by your application (but make sure your doing what you want, and that your doing them in the right order when doing the oppisite direction).
If I encrypt, compress, write to file .. then on the way out I need to read from file, decompress and then decrypt (oppisite order).
It's good to know the ones you use a lot... But being a good programmer has less to do with memorizing libraries and more to do with knowing where to get good answers quickly. In general, you don't want to read all the documentation ever written on every language before writing a line of code, but rather to write a lot of code and know where to look things up when you get stuck.
- Status