Corrections to Chapter 8 of Java I/O, Streams in Memory

p. 146: Near the bottom of the page "Th ByteArrayInputStream class reads data" should of course be "The ByteArrayInputStream class reads data"

p. 148: The code fragment at the top of the page uses an i <= 1024 instead of r < 1024. The entire fragment should be:

ByteArrayOutputStream bos = new ByteArrayOutputStream(1024);
DataOutputStream dos = new DataOutputStream(bos);
for (int r = 1; r <= 1024; r++) {
  dos.writeDouble(r * 2.0 * Math.PI);
}

p. 151: In the third line of code at the top of the page,

pin.connect(pos);

should be

pin.connect(pout);

p. 151: The last line of the fourth paragraph isn't true. PIPE_SIZE can't be overridden because it's a static field that's tied to the class rather than the instance. (You can shadow it in the subclass with another field named PIPE_SIZE but that doesn't replace any references to the original field in the superclass.) What you can do is subclass PipedInputStream, and provide a larger buffer in your constructor irrespective of the value of PIPE_SIZE. For example,

import java.io.*;

public class BiggerPipedInputStream extends PipedInputStream {

  public BiggerPipedInputStream() {
    this(2048);
  }

  public BiggerPipedInputStream(int bufferSize) {
    buffer = new byte[bufferSize];
  }

  public BiggerPipedInputStream(PipedOutputStream pout) throws IOException {
    this(pout, 2048);
  }

  public BiggerPipedInputStream(PipedOutputStream pout, int bufferSize) 
   throws IOException {
    super(pout);
    buffer = new byte[bufferSize];
  }
  
  public int getBufferSize() {
    return this.buffer.length;
  }

}

However, if you do this then any code that uses PIPE_SIZE instead of buffer.length is likely to fail. Probably it's best just not to do this at all.

Thanks to Leo Baschy for spotting this one.

[ Java I/O Corrections | Java I/O Home Page | Table of Contents | Examples | Order from Amazon ] ]