Originally posted by Jim Yingst:
[Max]: Correspondingly, if there is one byte then this method will block until at least one byte is read
is direct logical corollary of
if there is at least one byte then this method will block until at least one byte is read
'at Least' implies evening up to an including that point.
Also agreed. But in the API, "that point" is 1, not 7, or anything greater than 1. (That is, the values read may certainly exceed 1, but the number guaranteed does not..) There are two "at least"'s (how's that for punctuation?) in the API quote above; either or both may be greater than one, but they're never implied to necessarily be equal to each other. They just share the same minimum value, 1.
[Jim]: Incidentally, consider this quote from InputStream's read(byte) method:
"If len is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at end of file, the value -1 is returned; otherwise, at least one byte is read and stored into b."
[Note - I forgot to add "emphasis mine" the first time I quoted this.]
[Jim]: Would you argue that this language implies that if Q bytes remain in the stream prior to end of file, and Q <= len, then Q bytes are stored into b? This seems like the same sort of situation as we've been discussing for FileChannel.
[Max]: <cough> I tend to think that it does, given the docos as interpreted above.[/b]
Eh, sounds like you too have caught that bug that's been going around. My sympathies; I know it can be frustrating.
What is your opinion then of the InputStream docs cited above? Specifically:
Does the InputStream read(byte) API imply that if Q bytes remain in a file, a FileInputStream read(byte) is guaranteed to block until all Q bytes are read? (Assuming the buffer is large enough?) Do you think that a FileInputStream actually does block (always, that is) until all Q bytes are read?
My apologies if this seems irrelevant to the FileChannel discussion, but the "at least" parts of the InputStream doc seem comparable to the point of our earlier dicsussion.
Certainly other parts of the InputStream docs are different, and I don't plan to get into an involved discussion of the InputStream docs as well - but if your answer to question 1 above is "no", I'd like to get at least an idea why you think the situation for FileInputStream is different fom FileChannel in this respect. Referring to documentation, that is - I know that the implementations are significantly different under the hood.
Because those who mind don't matter and those who matter don't mind - Seuss. Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton