Search in Book Reviews

So why would I feel a bit disappointed to find it in my Christmas stocking? Well, to be frank, the word that comes to mind is dull. It lacks that buzz that you get when the author is excited by the topic and to many of us Java anoraks; the topic of Beans is exciting. A lightweight component architecture integrated into your programming language and not tainted by association with M---ft? Fantastic.

Is Robert Englander a Beans enthusiast? It is hard to say. He takes us through one of those simplified case studies that have bored text book readers since Caxton, this time a temperature control simulator. This is not a great example since it hardly cries out for component technology. There are plenty of better candidates: what about something more user-interface oriented such as a widget for list display, which might even be useful? Or to make the point that Beans don't have to be user interface components, a simple keyed datastore? Or how about a document architecture, to show how Beans can cooperate to make a greater whole?

The problem with an unexciting case study is that when the author asks you to wade through reams of code to understand a point, the natural response is to flip pages until something more interesting comes up. So you may miss something.

My other quibble about the book is that he says very little about whether he thinks the Beans model is a good one, or not and how it should best be used. For example, does the properties approach if over- used encourage the breaking of encapsulation? Is the model suitable for distributed architectures? He makes a point at one stage about a problem with the event model in a multi-threaded environment, but does not provide a solution. (The net effect of the problem is that it may happen that a client de-registers for an event but for a brief interval afterwards may still receive that event. A careful choice of data structure for the list of clients can avoid the problem).

At the end of the book he covers the topic of integration with ActiveX. I suppose that this is unavoidable. My own knowledge of this particular subject is minimal so I can say only that this chapter appears to have less depth than the rest of the book, but since not all Beans developers are interested in ActiveX it warrants a less extensive treatment.

In summary, a book to buy if you already know you want to develop using Beans, but not one to persuade yourself or others to do so.