I enjoy hearing from readers, whether with general comments about how this could be a better book, specific corrections, other topics you would like to see covered, or just war stories about your own network programming travails. You can reach me by sending email to [email protected]. Please realize, however, that I receive hundreds of email messages a day and cannot personally respond to each one. For the best chance of getting a personal response, please identify yourself as a reader of this book. If you have a question about a particular program that isn’t working as you expect, try to reduce it to the simplest case that reproduces the bug, preferably a single class, and paste the text of the entire program into the body of your email. Unsolicited attachments will be deleted unopened. And please, please send the message from the account you want me to reply to and make sure that your Reply-to address is properly set! There’s nothing quite so frustrating as spending an hour or more carefully researching the answer to an interesting question and composing a detailed response, only to have it bounce because my correspondent was sending from a public terminal and neglected to set the browser preferences to include an actual email address.

I also adhere to the old saying, “If you like this book, tell your friends. If you don’t like it, tell me.” I’m especially interested in hearing about mistakes. This is my eighth book. I’ve yet to publish a perfect one, but I keep trying. As hard as the editors at O’Reilly and I worked on this book, I’m sure that there are mistakes and typographical errors that we missed here somewhere. And I’m sure that at least one of them is a really embarrassing whopper of a problem. If you find a mistake or a typo, please let me know so that I can correct it. I’ll post it on the web page for this book at http://metalab.unc.edu/javafaq/books/jnp2e/ and on the O’Reilly web site at http://www.oreilly.com/catalog/javanp2/errata/. Before reporting errors, please check one of those pages to see if I already know about it and have posted a fix. Any errors that are reported will be fixed in future printings.

You can also send any errors you find, as well as suggestions for future editions, to:

To ask technical questions or comment on the book, send email to:

For more information about O’Reilly books, conferences, software, Resource Centers, and the O’Reilly Network, see our web site at:

Let me also preempt a couple of nonerrors that are often mistakenly reported. First, not all the method signatures given in this book exactly match the signatures given in Sun’s javadoc API documentation. In particular, I often change argument names to make them clearer. For instance, Sun documents the parse( ) method in the HTMLEditorKit.Parser class like this:

public abstract void parse(Reader r, HTMLEditorKit.ParserCallback cb,
 boolean ignoreCharSet) throws IOException

I’ve rewritten that in this more intelligible form:

public abstract void parse(Reader input, HTMLEditorKit.ParserCallback  
 callback, boolean ignoreCharSet) throws IOException

These are exactly equivalent, however. Method argument names are purely formal and have no effect on client programmers’ code that invokes these methods. I could have rewritten them in Latin or Tuvan without really changing anything. The only difference is in their intelligibility to the reader.

Furthermore, I’ve occasionally added throws clauses to some methods that, while legal, are not required. For instance, when a method is declared to throw only an IOException but may actually throw ConnectException, UnknownHostException, and SSLException, all subclasses of IOException, I sometimes declare all four possible exceptions. Furthermore, when a method seems likely to throw a particular runtime exception such as NullPointerException, SecurityException, or IllegalArgumentException under particular circumstances, I document that in the method signature as well. For instance, here’s Sun’s declaration of one of the Socket constructors:

public Socket(InetAddress address, int port) throws IOException

And here’s mine for the same constructor:

public Socket(InetAddress address, int port) 
 throws ConnectException, IOException, SecurityException

These aren’t quite the same—mine’s a little more complete—but they do produce identical compiled byte code.