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