Some quirks in InputStream.read() ?

Discussion in 'Java' started by DaLoverhino, Jan 23, 2005.

  1. DaLoverhino

    DaLoverhino Guest

    Hello. I have a FileInputStream, and I try to do the following:

    //Save the file's content into a String
    while( (readcount = in.read( buffer, 0, buffer.length) != -1) {
    // Add buffer to an ever growing string.
    }

    Now, what I'm noticing is that my buffer.length == 256, and the
    tail end of the file is not being loaded into the string.

    So what it appears like is happening is that I ask for 256 bytes,
    the FileInputStream can only give me say 18 bytes, so it then
    returns a -1.

    I was expecting in.read(...) to return 18, then on the next call
    return -1.

    I went on the sun site and found out there's nothing addressing this
    specific situation. So does that mean, if I change compilers/machines,
    this code could 'do the right thing'?

    Does it mean, I have to use available() in order to ensure proper
    behavior
    across all platforms (that is hardware, compiler, JVM.)? It would seem
    against the spirit of Java if it the above code does different things
    on
    different platforms? I must be missing something here.
    thanks for your time.
    DaLoverhino, Jan 23, 2005
    #1
    1. Advertising

  2. On 23 Jan 2005 00:11:59 -0800, DaLoverhino wrote:
    > Hello. I have a FileInputStream, and I try to do the following:
    >
    > //Save the file's content into a String
    > while( (readcount = in.read( buffer, 0, buffer.length) != -1) {
    > // Add buffer to an ever growing string.
    > }
    >
    > Now, what I'm noticing is that my buffer.length == 256, and the
    > tail end of the file is not being loaded into the string.
    >
    > So what it appears like is happening is that I ask for 256 bytes,
    > the FileInputStream can only give me say 18 bytes, so it then
    > returns a -1.
    >
    > I was expecting in.read(...) to return 18, then on the next call
    > return -1.


    That's what it should do. Post your real code, most likely that's
    where the error is.

    > Does it mean, I have to use available() in order to ensure proper
    > behavior across all platforms (that is hardware, compiler, JVM.)?


    In general, avoid the use of available(). At the very least, it will
    make it difficult for you to detect EOF.

    /gordon

    --
    [ do not email me copies of your followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
    Gordon Beaton, Jan 23, 2005
    #2
    1. Advertising

  3. Indeed it should return 18 bytes first and then -1.

    Another aspect: If you're really reading from a file (especially a large
    one), you should use a buffer which is significantly larger than 256 - the
    performance is way too poor otherwise because you make the system busy doing
    I/O.

    E.g. I have written a file synchronisation tool and did some performance
    tests writing flash memory (1GB UltraII SD-Card) on Windows. Developing
    software since 1988 I was a little bit conservative about buffer memory and
    started with 512 bytes. It turned out that my application required an hour
    run time to write about 62 MB to the flash memory while the Explorer
    required less than a minute!

    I then ran a lot of tests with differing buffer sizes and it turned out that
    the optimum buffer size is 2MB (2*1024*1024)! With this buffer there was
    finally no difference to the Explorer's performance.

    Of course, if you use such a big buffer you should make sure it's reused
    whenever possible and freed for the garbage collection asap. You will be
    wasting a lot of memory otherwise...

    Regards,
    Christian
    Christian Schlichtherle, Jan 23, 2005
    #3
  4. Andrew Thompson, Jan 23, 2005
    #4
  5. DaLoverhino

    DaLoverhino Guest

    Yeah. You are right. I found my error, in five minutes
    after I posted to this usenet! Ugh, makes me feel
    retarded. Hey, thanks anyways.

    The problem was in the buffer. I'm so use to a
    nul char from my C days, that what I was seeing
    on my display was the entire file, plus the remaining
    'junk' in my buffer which wasn't the end of the file.


    Anyways, the question still remains, I guess.
    The sun site doesn't state that it should return
    18 (less than buffer size), then -1. Or is this
    implied from the text? I mean I think it's implied
    in the text, but, I don't know....

    Thanks everybody.
    DaLoverhino, Jan 23, 2005
    #5
  6. On 23 Jan 2005 15:26:04 -0800, DaLoverhino wrote:
    > Anyways, the question still remains, I guess.
    > The sun site doesn't state that it should return
    > 18 (less than buffer size), then -1. Or is this
    > implied from the text? I mean I think it's implied
    > in the text, but, I don't know....


    I think the text is quite clear.

    From FileInputStream.read():

    Returns the total number of bytes read into the buffer, or -1 if
    there is no more data because the end of the file has been reached.

    Obviously you haven't reached EOF yet if there are 18 bytes remaining.

    InputStreams would be pretty useless if you immediately reached EOF
    simply because you didn't know how much data was remaining.

    /gordon

    --
    [ do not email me copies of your followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
    Gordon Beaton, Jan 24, 2005
    #6
  7. DaLoverhino

    Rogan Dawes Guest

    DaLoverhino wrote:
    > Yeah. You are right. I found my error, in five minutes
    > after I posted to this usenet! Ugh, makes me feel
    > retarded. Hey, thanks anyways.
    >
    > The problem was in the buffer. I'm so use to a
    > nul char from my C days, that what I was seeing
    > on my display was the entire file, plus the remaining
    > 'junk' in my buffer which wasn't the end of the file.
    >
    >
    > Anyways, the question still remains, I guess.
    > The sun site doesn't state that it should return
    > 18 (less than buffer size), then -1. Or is this
    > implied from the text? I mean I think it's implied
    > in the text, but, I don't know....
    >
    > Thanks everybody.
    >


    Sounds to me like you are not copying the right amount of data from your
    buffer into your output file.

    The "correct" idiom is something like:

    InputStream is;
    byte[] buff = new byte[BUFFSIZE];
    int got;
    while ((got = is.read(buff)) > -1) {
    // do something with buff[0..got]
    // e.g. os.write(buff, 0, got);
    // NOT os.write(buff);
    // OR os.write(buff, 0, buff.length);
    }

    --
    Rogan Dawes

    *ALL* messages to will be dropped, and added
    to my blacklist. Please respond to "nntp AT dawes DOT za DOT net"
    Rogan Dawes, Jan 24, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. R
    Replies:
    5
    Views:
    2,091
    Kevin McMurtrie
    Mar 13, 2005
  2. kayodeok
    Replies:
    20
    Views:
    821
    Toby A Inkster
    Nov 1, 2003
  3. Jeff Thies

    quirks mode and IE5 vs IE6

    Jeff Thies, Feb 12, 2004, in forum: HTML
    Replies:
    26
    Views:
    2,450
    =?ISO-8859-1?Q?Andr=E9s_Sedano?=
    Feb 14, 2004
  4. Michael Jaeger

    quirks mode

    Michael Jaeger, Apr 28, 2004, in forum: HTML
    Replies:
    10
    Views:
    877
    Jeff Thies
    May 5, 2004
  5. chad kline

    piping/reading stdin quirks.

    chad kline, Oct 10, 2003, in forum: C Programming
    Replies:
    6
    Views:
    440
    Irrwahn Grausewitz
    Oct 11, 2003
Loading...

Share This Page