Why do book publishers wantonly destroy trees? This 900-page 'book' is half-filled with almost comment-free code listings from the CD (at one point this is excused with 'maybe your library copy is missing the CD')! and another third is full of annotations for the same code. What is left is a (very) short walk through accessing local DBF (Foxpro/DBase) files in Java. With the odd diver-sion into the author's own String class, a chapter on writing AWT layout managers and several digressions into optimising disc access to make database accesses (via B-Trees) as fast as possible, this is a very small book hiding inside a large one. While the section on B-Trees is very informative and some of the history of DBF files interesting, this is fundamentally a walk-through of a GUI application to display data from said DBF files.
The code itself is of a very poor standard; public data items abound (complete with accessor functions too in some cases), along with protected data and methods (with no explanations). But adding to this set of horrors are catching (and then ignoring) all exceptions from standard components, calling a GUI 'MsgBox' type function in an error path of a low-level component and in the second chapter the existence of two public booleans, where 'setting both to
trueis a programming error' where the author himself admits that he can't predict what would happen. While this isn't meant to be a book on programming, I find this sort of thing inexcusable and only serves to drag down the standard of Java being written out in the real world - and all this from a so-called 'acclaimed Java programming expert'.
Although determined in places to be a book purely about databases, it manages to contain a chapter on writing custom 'layout managers' for the Java AWT; and the later sections degenerate into the author's personal pursuit of 'efficiency' in his B-Tree implementation, regardless of how interesting this might be to the reader. I felt like I was at a bad party stuck with the local programming bore!
The author appears to be writing from an intellectually-superior vacuum; his way is always the best and all other published work is considered over-complicated (he rubbishes standard database normalisation in a couple of sentences in favour of his 'easier, more teachable, better' approach) or not efficient enough. Butwhen he starts to reach the limits of his own knowledge, he gives up rather than doing the research to give the reader a complete picture.
He also chases the 'efficiency' dragon mercilessly, apparently regardless of whether the reader wants or needs these 'efficiencies'; the last few chapters are relentless in this pursuit (trying to optimise the number of OS file accesses) and as a result fails to get as far as maintaining relational integrity or performing transactions. The overall feel at the end is simply termination due to sheer size rather than completeness of topic; and it is hard to ignore the temptation to call the subject matter '1980s database technology using Java'.
This appears to have been one of the flood of Java books released when Java was a trendy thing to have on the cover of your books; I afraid I can't recommend either the book or the author, despite the accolades on the back cover. It remains a curio for those people who might want to access DBF files in Java, although I'm sure such information is available elsewhere for those who might want it.