Java I/O Unconfirmed Errata

Errata

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question

Version	Location	Description	Submitted By
Printed	Page 13 Sentence after the javac example	While the text states that "The list of available encodings is given in Table A-4.", I couldn't find that table in the Appendix.	Anonymous
Printed	Page 25 bottom of page	The output of AsciiChart is wrong.	Anonymous
Printed	Page 29 Last but one paragraph	"Then sync() method..." probably should read "The sync() method..."	Anonymous
Printed	Page 90,91 chapter 6 code example DecimalFilter.java and HexFilter.java	These two examples in fill() method that implement from class DumpFilter, but buf field in the class DumpFilter marked private so that subclass can't see it, as well as index field in the class DumpFilter.	Anonymous
Printed	Page 100 9.3. Communicating Between Threads Using Piped Streams	FibonacciDriver class must be wrong.It's the same as FibonacciConsumer.class	Anonymous
Printed	Page 157 Example 9-5	The FibonacciDriver example contains the FibonacciConsumer code.	Anonymous
Printed	Page 166 Subsection "Checking the state of a deflater"	The text should perhaps mention that (at least according to the Java 5/6 API) the methods getBytesRead() and getBytesWritten() are preferred over getTotalIn() and getTotalOut(), as they return a long rather than an int and thus can handle larger files.	Anonymous
Printed	Page 170 Subsection "Checking the state of an inflater"	The text should perhaps mention that (at least according to the Java 5/6 API) the methods getBytesRead() and getBytesWritten() are preferred over getTotalIn() and getTotalOut(), as they return a long rather than an int and thus can handle larger files.	Anonymous
Printed	Page 178 1st paragraph	"The ZipFile class contains two constructors." must be "The ZipFile class contains three constructors."	Anonymous
Printed	Page 183 Last paragraph before the section "The ZipOutputStream Class"	In addition to the six setter methods mentioned in the text, there is a method setCompressedSize() for setting the size of the compressed entry data.	Anonymous
Printed	Page 212 Method signatures after the 1st paragraph	While the text states that the signatures for the two unpack() methods of the Pack200 class are public void unpack(File in, OutputStream out) throws IOException public void unpack(InputStream in, OutputStream out) throws IOException they are in fact public void unpack(File in, JarOutputStream out) throws IOException public void unpack(InputStream in, JarOutputStream out) throws IOException	Anonymous
Printed	Page 285 3rd paragraph	"The main() method tests the program by serializing and deserializing a SerializableVector ..." must be "The main() method tests the program by serializing and deserializing a SerializableList ..."	Anonymous
Printed	Page 285 4th paragraph	Sample output of 5th line (between null and 9) must be "Element 5", but it's printed as "Element 1".	Anonymous
Printed	Page 315 Example 14-2 Class NIODuplicator	Main method contains an infinite while loop. This is due to the failure to test whether more data needs to be written before invoking the compact() method on the buffer object. Automatically, invoking compact() without testing, ends up in resetting the position pointer to 0 and limit pointer to capacity which causes the 2nd test condition in the while loop (buffer.hasRemaining()) to always return true. The readers should also beaware that the first test condition also perputates the infinite loop since bytesRead >= 0 will always be true. This is due to the fact that the use of the FileInputChannel method read() in this code returns 0 and not -1 when no more data is read. To get the read() method to return a -1 when no more data is read will require that the buffer be cleared at some point after the write() method is invoked.	Anonymous
Printed	Page 316 1st paragraph	The statement, " When the duplicate is created, its position and mark are set to 0 and its limit is set to the capacity, regardless of the position , mark and limit in the orginal buffer." is false. The position, mark and limit pointer of the duplicate buffer are initialized to the same values as the original buffer. This can be verified by both testing and by viewing the source code for the undocumented HeapByteBuffer class which extends the ByteBuffer class.	Anonymous
Printed	Page 320 bottom	Some mistakes are in code fragment at page bottom: [ERR] ByteBuffer buffer = buffer.allocate(8008); [OK] ByteBuffer buffer = ByteBuffer.allocate(8008); [ERR] roots.putDouble(i, Math.sqrt(i)); [OK] buffer.putDouble(i, Math.sqrt(i));	Anonymous
Printed	Page 321 1st paragraph	Some mistakes are in code fragment at page top: [ERR] ByteBuffer buffer = buffer.allocate(1001 * DOUBLE_SIZE); [OK] ByteBuffer buffer = ByteBuffer.allocate(1001 * DOUBLE_SIZE); [ERR] roots.putDouble(i* DOUBLE_SIZE, Math.sqrt(i)); [OK] buffer.putDouble(i* DOUBLE_SIZE, Math.sqrt(i));	Anonymous
Printed	Page 357 second sentence following third code example	Sentence "Should the key become ready again in the future, is it included in the next set returned by readyKeys()" is incorrect - there is no readyKeys(). readyKeys() should be selectedKeys() (and really, as I understand it, it's more accurate to state that it will be returned next next time select() is called.	Anonymous
Printed	Page 395 first paragraph under "Temporary Files"	"The File class provides two [createTempFile] methods that create temporary files that exist only as long as the program runs" (emphasis mine) -> as the author points out further down, there is a separate "deleteOnExit" method that must be called if you want temp files (or any other files) to be deleted on exit.	Anonymous