Java in a Nutshell

Errata for Java in a Nutshell

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 Note Update

Version Location Description Submitted By Date Submitted
PDF Page 331
Description of the -C dir option

This error is in the 4th and 5th editions of Java in a Nutshell, I suspect that it is also wrong in the 6th edition, but I don't own that version. According to the Oracle documentation for the jar command (and experimental observation), the -C dir option only affects the next file or directory specified. See -C dir When creating (c) or updating (u) a JAR file, this option temporarily changes the directory while processing files specified by the file operands. Its operation is intended to be similar to the -C option of the tar utility.For example, the following command changes to the classes directory and adds the Bar.class file from that directory to my.jar: jar uf my.jar -C classes Bar.class The following command changes to the classes directory and adds to my.jar all files within the classes directory (without creating a classes directory in the JAR file), then changes back to the original directory before changing to the bin directory to add Xyz.class to my.jar. jar uf my.jar -C classes . -C bin Xyz.class ----- Note that it says that it changes back to the original directory before processing the second -C dir option. Your documentation should say something like: Used within the list of files to process; it tells jar to change to the specified dir while processing the first subsequent file or directory. The subsequent file or directory name is interpreted relative to dir and is inserted into the JAR archive without dir as a prefix. Any number of -C options can be used; each -C option only applies to a single file or directory. The directory specified by a -C option is interpreted relative to the current working directory, not the directory specified by the previous -C option. Java 1.2 and later.

Bruce Albrecht  Jan 19, 2017 
Printed Page 781
6th date/time code from bottom of page %tI

Page 781, Dates and Times, 6th up from the bottom of the page %tl should be %tI (uppercase India, not lowercase lima - they look the same). If it is a font thing, it is indistinguishable from the 2nd up from the bottom of the page. There is no context with these codes whereas in ISO8601 (%tF description) one can see that it is a capital I. Perhaps you could add (uppercase I - first person singular) and (lowercase l - as in lizard) - or just change the font.

Alec Matthews  May 13, 2014 
Printed Page xx
3rd paragraph

Java Examples in a Nutshell is like Chapter 4 of this book should be: Java Examples in a Nutshell is like Chapter 5 of this book

Anonymous  Jan 21, 2014 
Printed Page 146
Center of page, paragraph "Let's pretend..."

"an LinkedIterator" should read "a LinkedIterator"

Luis Mendo  Sep 05, 2013 
Printed Page 139
2nd line of code (comments)

"It may be quicker make" should read "It may be quicker to make"

Luis Mendo  Sep 05, 2013 
Printed Page 136
4th line

In the phrase "the extends clause of an interface definition", "extends" should be typed with the font used for code

Luis Mendo  Sep 05, 2013 
Printed Page 264
8th line from bottom

// Set limit to 0; >> // Set position to 0;

WDB  Sep 21, 2010 
Printed Page 213
First code example (2nd paragraph)

In the pattern string, the '^' appears to be (a) unnecessary (b) confusing. If removed, the pattern still successfully matches.

Steve  Jun 02, 2010 
Safari Books Online 4.1.3
section 4.1.3:

From Java In a Nutshell, 5th Edition, section 4.1.3: "Second, consider List methods such as add() that are declared to accept an argument whose type is specified by the type parameter. This is the more surprising case: when the type parameter is unknown, the compiler does not let you invoke any methods that have a parameter of the unknown type because it cannot check that you are passing an appropriate value. A List<?> is effectively read-only since the compiler does not allow us to invoke methods like add( ), set(), and addAll( )." This is incorrect and misleading. First, the compiler *does* allow you to invoke the add() method in this example -- it simply requires that a suitable value (a subtype of the capture variable) be provided. The null reference is such a value, and so it is always possible to write "l.add(null)" when l has type List<?>. Second, there are other ways to mutate a List<?> in addition to directly invoking add(), set(), or addAll(). The clear() method, for example, mutates a collection without making reference to the class's type parameter. And methods like Collections.sort() allow a name to be inferred for the unknown type, which then permits values of inferred type T to be returned by get(), etc., and then passed to add(), etc. It's dangerous to suggest that a read-only interface to a collection can be had by simply weakening its type argument. Instead, programmers should be encouraged to use Collections.unmodifiableList(), etc., and, for better compile-time enforcement, consider weakening the type to Iterable<T> (this interface still doesn't guarantee read-only access statically, though, because the Iterator<T> interface has a remove() method). óDan

Anonymous  Apr 07, 2009