🚀 go-pugleaf

Thanks Owen for the explanation.  I understand better now what is going
on.

I'll work with this.

Alan

Owen Green wrote:
> 
> "Alan Shiers" <ashiers@hfx.eastlink.ca> wrote in message
> news:3D21EC78.228A5CD3@hfx.eastlink.ca...
> 
> > >
> > >     byte[] buffer = new byte[128];
> > >     int n;
> > >     while ((n = in.read(buffer)) >= 0)
> > >       out.write(buffer, n);
> >
> >
> > This while loop is confusing to me.  You dimension an array at 128
> > elements and pass it to the read(byte[]) method of DataInputStream.
> Which populates the array with /up to/ 128 bytes of data on each read.
> 
> > Where does the size of the file figure into all this?
> In the boolean condition (n = in.read(buffer)) >= 0, which does two things:
>   n = in.read(buffer) assigns the int n to the number of bytes that have
> just been read
> (..) >= 0 tests that this is greater than 0; if EOF is detected then the
> stream will return -1, for example, so this condition gurantees that the
> loop will continue until all the data in the file has been read. At no point
> do we actually need to know the size of the file; it simply isn't relevant.
> 
> > The thing that is throwing me is that the file maybe much bigger than
> > 128bytes.
> Hence the loop.
> 
> >Is the read() method going to automatically increase the size
> > of the array?
> No, this is impossible with Java arrays.
> 
> What happens is that for each iteration of the loop up to 128 bytes of data
> are read from the input stream. The actual number of bytes read is stored in
> a variable, n, so that we can ensure that the correct number are written to
> the output stream. The loop has an exit condition based on the fact that the
> general contract of input stream is for EOF to be signalled with a negative
> number (and the assumption that a read of 0 bytes would also indicate the
> absence of any more useful data).
> 
> This technique offers an improvement over trying to read an entire file in
> at one time, as the resource overhead remains pretty much constant, i.e. the
> size of your buffer, and as such far more able to deal with files of any
> size. It also provides an improvment to reading a byte at a time by
> requiring far less method calls (roughly 128th of the number in this case).
> 
> hth
> Owen