This content has been marked as final. Show 11 replies
Because it can return 257 unique results and it can't fit them into an 8-bit byte.
I understand that the stream is read one byte at a time, and without adding information to the stream, the bytes are converted to integers leaving the 24 most significant bits at zero. Where do the two extra possible values come from and what do they represent? Furthermore, if it is a question of 257 possible values, why is space not saved by returning the values as short primitives. I am not saying that you are wrong; I clearly do not understand something in the underlying process.
I understand that the stream is read one byte at a time, and without adding information to the stream, the bytes are converted to integers leaving the 24 most significant bits at zero.
Where do the two extra possible values come fromOne extra value. There are 256 possible byte values - 0 to 255. The one extra value is documented in the Javadoc.
and what do they represent?See the Javadoc.
Furthermore, if it is a question of 257 possible values, why is space not saved by returning the values as short primitives.Good question. Who can say? To be fair, I expect that using int is far more efficient on a modern processor, and the space saving will be minimal.
I am not saying that you are wrong;Jolly good.
I clearly do not understand something in the underlying process.See the Javadoc.
So, the answer to my question is that a 64 bit datum is much the same as a 32 bit or 16 bit datum for most machines these days. I suspected something like that. Thanks for your input.
No, that's not the answer to your original question. The answer to your original question is that that method needs to return more possible values than it can fit in a byte. As I already said.
Sure. That is part of the explanation. Thanks again for your input. But that doesn't explain why the information being read cannot be stored in a short, for example, using two bytes. It seems wasteful to store slightly more than one byte of information in four bytes.
Incidentally, where do I find the documents to which you refer?
Oh, I see what you mean. But that wasn't your original question!
If you think about it, all the processor registers on a modern processor are 32 bits wide. And you're never going to store the return value of read() in anything other than a local variable until you test it for -1 and which point you will then store the byte into a byte or something. So you're only wasting the storage space in that one temporary variable. At most 2 bytes in total. In reality, nothing at all, since a short would still occupy a whole processor register.
The Javadoc is included with the JDK, and the source for all runtime library (java.*, etc.) is also included in the src.zip file. The Javadoc can also be found online here: [http://java.sun.com/javase/6/docs/api/] (assuming you're using JDK 6)
This suggests that you aren't familiar with the Javadoc. You should become familiar with it, and quickly! It answers most questions, and the source code answers most of the rest.
I am constantly using the Java documentation on line. After reading your comment I searched my system and in
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home a docs.jar file.
I extracted the jar with cl: sudo jar -xf docs.jar
And this is the same documentation I have been using on line. So, nice to know that I have it on my system, but it is not new to me. I did not know that this is what you meant with the term Javadocs.
Thanks for your help.
I have a closely related question: After an int is retrieved using the read() method,
if the int is not -1, is it correct to restore that to a byte value simply by saying
int x = f.read()
byte b = (byte)x
Yes, that's the idea.