Most programming books these days seem have titles that bear little relation to their content. Publishers cynically sprinkle words like "Advanced" or "OO" around because it gets the books on company shelves. "Java After Hours", however, does exactly what it says on the tin. This is not code to impress your boss or your colleagues. It's not even "macho" code to impress hackers, but it is probably at about the right level for "play code" if you want to dip your toes into different areas of Java technology.
The layout and style of the 10 chapters is easy to follow. Code is incrementally introduced with with lots of explanation and a little less padding that usual. The programs are built up in roughly the way you would create them so you aren't just reading through a source file from beginning to end. As key class are encountered, mini references are provided to give an overview of important methods. The documentation for these methods is often laughable (e.g. getName() - Gets the name) but it still works.
The projects gradually build up a body of knowledge in a few core areas of Java technology. The blurb focuses on what the applications do, so you might be interested to know that by the end of the book you'll have more than a passing familiarity with AWT (including Graphics2D, the awt.image package and the awt.Robot), Swing, SWT, JSP and Sockets. Threads are covered, but I have serious reservations about the material. Synchronisations are not covered, instead we are told that "The standard technique for communicating with threads is with Boolean flags". Bizarrely, the author even confesses in a sidebar that he once crippled a client's servers with runaway threads. Read this as "ignore everything I say about threads".
It's a real shame, because I would like to recommend this book to people that need to branch out from the Java they use at work, but the technical inaccuracies are quite serious. I have already heard people say they based real-world code on the techniques in this book. As well as the problem with threads, the author seems to be claiming that HTTP Basic Authentication is more secure than HTML forms with password controls. It all makes me very uneasy about what else is flawed.
