Errata List for
Understanding Object-Oriented Programming with Java

(Revised edition

by Timothy A. Budd

Published by Addison-Wesley Longman

461Should mention package protection (see footnote) (rw)
464Exercise 5, method is called substring, not substr (rw)
569Balls can run off screen (see balls at the edge of ball worlds) (jk)
569No particular reason why FrameWidth and FrameHeight should be public, would be better as private (rw)
573use of short names dx and dy, see short names
577Sec 5.5, par 3, See earlier comments on package protection (rw)
685method named dy easily confused with similarly named field in Chapter 5, suggest flip (jk)
693First line of code, Fire=>fire (lower case f) (jk)
7117Line 8, should use x and y rather than recomputing e.getX() (nm)
81258.3 par 2, ``subclasses of PinBallTarget'' => implementations (see also page 162) (jane)
10162line 1, ``subclasses'' => ``implementations'' (PinBallTarget is an interface, not a class (nm)
11183Dicussion of clone misleading (see clones)
11187Line -10, "abc" should be ``new String("abc")'' (see footnote on String Constants) (mark)
11188Line 6, ``between objects'' => ``between objects of the class'' (rw)
11188Line -2, ``associative'' => ``transitive'' (rw)
12203par 2, remove ``is deferred, it'' (rw)
13228why is variable dlg final? (I don't know). (rw)
14236last par, first line, FilterInput => FilterInputStream (rw)
20340Line -8, variable sg => g (vl)
21351Applet paramaters and quotes, see footnote (rw)


Protected fields and packages
On page 61, 77 and elsewhere I only mention the use of protected fields in controlling access from subclasses. In fact, protected fields can be referenced by any class in the same package. On the one hand, the language permits this and so it should be discussed. On the other hand, it is usually a bad idea and so should be avoided.

Balls at the edge of the Ball World
Dr. John Kuchenbrod, of Emory and Henry college, has noted that the Ball world described in Chapter 5 treats the balls as unit sized objects, so that in fact the tests in Line 25 and 27 of Figure 5.2 are incorrect, and permit a ball to move partly off the screen. Indeed this observation is valid, but was a conscious decision on my part. In presenting any example there is always the problem of too many details getting in the way of the reader understanding the point you are making. In this case the code might be thought of as slightly more correct by using 6 instead of 0, and FrameWidth-6 instead of FrameWidth. But then I would need to explain the 6--for example why 6? It's an arbitrary number that could easily have been something else -- so perhaps it would be better to have a method in Ball that returns its diameter, and so it goes getting more complex. In this case there is an interesting situation where this bug becomes a feature -- because the display of the portion of the ball that is off the screen is clipped, balls in this situation look squishy, sort of like they are being compressed as they hit the wall.

Short Names
I've received some complaints about my use of very short variable names. Normally, I agree that it is much better to use longer and more descriptive names for any variable that is long lived. However, I see no problem in using short names for values that have very small scopes, i.e., loop index variables and parameters. The one place were I have not followed this guideline, and the one that seems to generate a lot of mail, is the use of the names dx and dy for the motion vectors in the Ball world. Here I can only plead the fact that the names derive from calculus and physics, where delta-x and delta-y (greek letters) are often used to represent a vector representing a change in motion. The names dx and dy are shorthand for these values. But, of course, the names are only memonic for those with a background in math or physics.

The discussion of the clone interface on pages 183-185 is misleading. This is made more-so by the intertwining of two issues that should probably be explained separately. These are the difference between shallow and deep copies, and the Java clone method. Furthermore, it would probably be better to explain these in reverse order, copies first and then clones, instead of the order given at present.

Here are some thoughts on how to first address the shallow versus deep copy issue. Having defined Box (on page 182), imagine we now define the following new class:

public class DoubleBox {
	public void setValue (int v) { innerBox.setValue(v); }
	public int getValue () { return innerBox.getValue(); }
	private Box innerBox = new Box();

	public DoubleBox copy () {
		DoubleBox newValue = new DoubleBox();
		newValue.innerBox = innerBox;
		return newValue;

A careful examination, such as the following, will show that if we create a double box, and they copy it, they actually share the same data areas (we can even use figure 11.3 for this).

DoubleBox a = new DoubleBox();
DoubleBox b = a.copy();
System.out.println("b is " + b.getValue());

This is a shallow copy. If, on the other hand, we replace the innerBox assignment in DoubleBox with the following:

	public DoubleBox copy () {
		DoubleBox newValue = new DoubleBox();
		newValue.innerBox = new Box();
		newValue.innerBox.setValue (innerBox.getValue());

Then we create a deep copy, as each doubleBox will have its own inner box.

(critical readers will note that the allocation of a new box is unnecessary, since it is already done when we create an instance of DoubleBox, but I haven't decided yet whether it contributes more or less to clarity to keep the assignment in the copy method).

Having (I hope) cleared up some of the confusion regarding shallow and deep copies, then in a separate section I should address the clone method.

The code at the top of page 184 should be as follows:

public Object clone () throws CloneNotSupportedException {
	DoubleBox newBox = (DoubleBox) super.clone();
	return newBox;

That is, all that is necessary is to invoke the inherited method from the parent class. This creates a shallow copy. Note that the user is free to override this and provide new behavior if, for example, they want to create a deep copy. (Well, I suppose I should also mention some of the other differences, such as throwing an exeception, and the fact that the clone method must return an object and not a DoubleBox).

String Constants and Equality
On page 187 I discuss the differences between identity and equality. Near the bottom of the page I use strings as an example. While the general idea is correct, this particular example unfortunately is not. Java compilers are supposed to be intelligent enough to recognize repeated uses of the same string constant, and create only a single object. This could be fixed by explicitly using the new operator on the strings, as in
	String a = new String("abc");
	String b = new String("abc");
However, since nowhere else do I ever use the new operator with string, a better solution might have been to use the wrapper class Double.

Applet Parameters and Quotes
This is not really an error, but rather something that could stand a bit more discussion. On page 351 I discuss the <param> tag and on page 351 I discuss the associated getParameter call in Java, although unfortunately I do not give an example of the latter. What may be confusing to the student is the use of quotation marks, and their common absence in many example programs. It is clear from the description of getParameter that both the name and the value are always treated as string, even if they look like numeric values. So the following are equivalent
<param name=foo value=12>
<param name="foo" value="12">
If no quote marks are found, the next word is taken as the value of the string. Following this logic, the only time that quote marks are really necessary is if a value happens to contain a space or a special character (such as a right angle bracket).

Grateful Acknowledgement

One or more of the errors reported above were found by the following individuals:
Dr. John A. Kuchenbrod, math/CS department, Emory and Henry College.
Jane from Argyll, a tutor for the course M301 at the Open University, UK.
Vegard Larssen, Student at the Norwegian University for Technolgy and Science, Trondheim, Norway.
Mark Thomas, a tutor for the course M301 at the Open University, UK.
Nigel Mercier, Cranbrook, Kent, student at the Open University, UK.
Ray Weedon, Open University, UK.

Where to Write

Send all reports of errors or typos to Professor Budd at

Last Modified: 14 February 2000