Errata

From APIDesign

Revision as of 13:55, 4 April 2009

Chapter 1

p. 13, para 2 - should "at its certain revision" be "at its current revision"? --David Biesack 20:25, 5 February 2009 (UTC)

Read the reply...

Chapter 7

Page 123: For the sake of consistency with other samples and to teach reader to be defensive, lookup and ic fields should be final.

Chapter 8

Page 132: Implementation of Playback interface should be named MyPlaybackPrints instead of MyCallbackPrints.

Page 134: There should be append method mentioned (instead of write) in this sentence: "This is reasonable behavior for implementors because those who subclassed Writer have not implemented the new write method."

Chapter 10

Page 160: Introducing the String class in re-export sample is bit artificial and decreases readability. At least it should be renamed to something like LibraryString.

Page 160: There suddenly appears the Query library in the text not being introduced anywhere. Don't get confused. The only important thing to know about this library is that it is returning the re-exported String on computeReply() method call.

Page 164: The text is unfortunately silently referring to the side note story (code completion). So when you read the text first and the NetBeans stories later you can get confused slightly.

Page 178: Type parameter is bit confusing. While most of the people are familiar with single uppercase letter (like T, E, V) and can easily recognize them as a type parameter author is using Configuration and switch to C just a few lines later.

Chapter 11

Page 195 and 196: It would be nice for the samples to have a bit wider context. They may be too hard to understand.

Page 203 and 207: Class names R and H are bit misleading as a single letter identifiers are usually used as type parameter names.

Page 209: The text is referring to the side note. You should read the side note first.

Page 214: Example of controlFlow is bit harder to understand as it is using regular expression for two lines of log without further explanation. In fact it is just manifestation of such possibility (not required for the sample in order to work).

Chapter 12

Page 231: There is no real explanation of what immutability means in Java. At least there should be link to other document on this topic.

Chapter 13

Page 241: In the scenario described Subversion behaves the same way as Mercurial, so it would not be possible to checkin changes without first synchronizing against the HEAD revision (assuming checking goes to HEAD). See, for instance, Subversion FAQ, question I'm trying to commit, but Subversion says my working copy is out of date?, answer 3.

Re: I've managed many times to do "svn ci" without being fully "svn up". I'll verify to be sure. --JaroslavTulach 13:55, 4 April 2009 (UTC)

Chapter 15

Page 274: Sample is bit unclear. It is probably a method returning boolean, but the method signature is not part of the example. RuntimeCheck is not mentioned anywhere so it is a magic function call from the reader's point of view.

Page 283: Misleading name of the type parameter in Digestor sample - Data. Single character would be much better choice.

Chapter 16

Page 298: The file containing API changeset is apichanges.xml, not apidesign.xml.

Chapter 18

Page 337: Typo in the sample. Instead of throw new IllegalStateException("Old visitor used on new exceptions") it should be throw new IllegalStateException("Old visitor used on new expressions")

Page 351: In paragraph Syntactic Sugar this reference is leaking from constructor so it is unsafe reference publication. In terms of cluelessness this risk should be mentioned together with link to proper explanation.

Chapter 19

Page 361: Referring to "sealed" packages without any explanation of this term.