Bitter Java
Bitter Java
By Bruce Tate
* Publisher: Manning Publications
* Number Of Pages: 368
* Publication Date: 2002-04
* Sales Rank: 583456
* ISBN / ASIN: 193011043X
* EAN: 9781930110434
* Binding: Paperback
* Manufacturer: Manning Publications
* Studio: Manning Publications
Editorial Reviews
Skip McCormick, co-author of Anti-patterns
“It is the rare computer science book that truly captivates me….I just couldn’t put Bitter Java down.”
JavaPro Magazine
“Does a great job of articulating a philosophical foundation on which good architects and programmers can build.”
Book Description:
Intended for intermediate Java programmers, analysts, and architects, this guide is a comprehensive analysis of common server-side Java programming traps (called anti-patterns) and their causes and resolutions. Based on a highly successful software conference presentation, this book is grounded on the premise that software programmers enjoy learning not from successful techniques and design patterns, but from bad programs, designs, and war stories — bitter examples. These educational techniques of graphically illustrating good programming practices through negative designs and anti-patterns also have one added benefit: they are fun.
Although some of the advice is valuable, the book should in no way be used as a direct source of clean code.
Pages 92, 113, 123, 132, etc. advocate using string building to create SQL queries. This technique is unreliable, in that it may create invalid SQL. It is also insecure, as it allows sending arbitrary expressions to the SQL server. It is also ineffecient, as it does not use the inline replacement syntax that most SQL servers allow for and can optimize.
Page 113 advocates using a numeric index based parsing methodology for handling the result set from an SQL query. This technique is weak and easily broken. Symbolic references, such as hash tables aligned with aliases in the SQL is a much stronger pattern that is much harder to break.
Page 113, 115, etc. advocate using strings for every type of data returned from the database. If the book advocates using a strongly typed language, why weaken it to a sub-Perl standard by using strings for all data types. I understand that this makes the JSP display code easier to write. If that is then intention then the model code is being weakened by the requirements of the view code.
Page 119 is using a for loop based indexing pattern over a returned results set. An enumeration pattern is best suited for this activity.
The section on caching presents a Perl based solution which is then replaced because the Perl did not cache. However, the author points out that the cache could have fit in memory. Most mainstream databases would have the database in memory and thus would only have the overhead of the network traffic, which in most cases is neglible. The author then proposes a solution with a singleton based cache which limits the entire deployment to a single web server (unless you want to put the singleton in another process, which gets you back to the neglible network overhead case.) A single server is much less scalable then multiple servers which use the database as cache. In short, this example throws the baby out with the bathwater.
Page 133 discusses the dynamics of a cache without introducing the notion of a forced cache flush. In complex caching systems a dependency mechanism for intelligent cache maintenance is a requirement. Certainly it merits at least a mention in this overview.
Page 137 makes reference to Listing 5.2, but no labelled listing 5.2 is to be found. Able readers will make the connection, but in general the listings should be numbered if they are to be refered to by number.