Re: data and object streams
Quote:
won't be able to read the data in the file
You can read the data with a data stream. The data written will NOT be ASCII text.
Quote:
want to output some int values to a .txt file: 5, 10, and 25.
What format/representation for the data do you want in the .txt file? I would assume you'd want ASCII characters in a .txt file. To get those you need to write Strings.
Re: data and object streams
Quote:
Originally Posted by
bbr201
also, can anyone provide a simple explanation of an object stream and an example of when you would use it?
Object streams allow you to save an object. An example might be for a program to save some internal state to be opened up at a later time, in the simplest case it can save one or more user preferences, in more complex cases save session and data values in J2EE web applications. The class must implement Serializable to be able to be saved in this manner.
Re: data and object streams
Quote:
Originally Posted by
Norm
What format/representation for the data do you want in the .txt file? I would assume you'd want ASCII characters in a .txt file. To get those you need to write Strings.
What advantage is there to using a data stream to output and read primitive data types?
In the case of a text file, it makes sense that you would want ASCII characters in the event that a human being wants to open the file and see the contents. So I assume in this case it would be best to work with a character stream.
But why ever choose the data stream then?
In other words, let's say you use another file to read and store values 'data.dat'. No human being will ever need to open the file and see the contents. It is only used by a program to store (and later read) int values. In this case, couldn't you use a byte, character, or data stream? How would you choose which to use?
I guess I am just confused in general. :-(
Re: data and object streams
Writing out as a binary file prevents you from manually having to figure out how to de-serialize the data into a useable object (i.e. re-create that object from the data). Java has a default serialization method that allows you to just open an object stream and then write out the file, instead of specifying "I want value A written first, then value B is written in this format,..." etc. etc.
Objects stored in binary are also smaller (in general) than the text representation of that object.
For example:
Say you have the double value 1.23456789012345e-126
To write that value out as a string, it would take 21 bytes (depending on the encoding), where as a normal double takes only 10 bytes of memory. That's more than twice the amount of data you need to process. For this simple example, it may not matter but I have worked on data that has millions of numbers (a lot of data sets even go into the billions, trillions, or higher), and for these data sets having twice the data to process is simply unacceptable. Also, it is extremely quick to serialize/deserialize a binary object compared to parsing a string representing the object.
And sometimes you just don't want humans to be able to open up and mess around with the files you're saving out :P