So, I’m at Barnes and Noble and manage to see the bottom shelf of the java rack chockablock with that worthy tome, Java Open Source Programming. Needless to say, i could not possibly be any less likely to spend any money on it. However, I thought it’d be worth taking it for a test drive in the enjoyable B&N cafe area.
Thus, said book and I made the long trek to the cafe, and sat down for an intimate book-to-man-to-book chat. It said some words, I said some harsh words, I nodded sometimes, I frowned at other times, and mostly I scoffed and snorted in disgust. It sat there and was eventually flung aside without being returned to the appropriate shelf. I tried to teach it a lesson in the only small way I could.
So, why shouldn’t you all rush out to buy this book? Well, where does one start? The title I suppose is as good a place as any. A more apt title would be ‘Developing web apps by avoiding all J2EE’. Perhaps ‘Stuff You Can Mash Together’ would have worked too.
The JUnit chapter, for example, is surprisingly trivial. Granted, it’s early on so perhaps the assumption is that the reader is still pretty ignorant and stupid and needs a serious amount of babysitting. We’re taught how to construct baby testcases, we’re promised a treatise on TDD (top down development or test driven development, depending on Joe Walnes’ time of the month). We’re told that to handle exceptions, we just declare the methods to throw Exception, yet there is no mention between the difference of a testcase error vs a testcase failure.
Moving on to the mock objects chapter. Here we have some frantic hand waving about how testing big system can be difficult, due to the problem of marshalling resources, environments, external API’s blahblah. All makes sense, and is a sensible intro to mockobjects. The author of this chapter however seems to have gotten bored of the idea fairly quickly, as the example provided is a trivial one which doesn’t really address any ‘real world’ situation where mocks might actually be useful (there’s no environment, resources, or complicated deps to mock).
The XWork chapter of course continues the fine tradition of outright lies to sell the benefits of this miracle cure. It claims that OSWorkflow uses/supports xwork, which of course is a complete lie. It also says that JPublish uses it (it was considered at some point as ‘the’ command framework then ditched, now it’s just supported), and has a misleading comment about webwork 1 being based on the same command framework (misleading at best).
It’s pretty clear that when that little gang of four got together, they politely listened to one another, then promptly went ahead and did what they individually wanted to do anyway. The transitions between chapters are jarring and confusing. There’s little to no warning of what’s coming up ahead (except of course where they say stuff like ‘in 10 chapters, you can read more about this!’).
Of course, we have the Atlassian plugs, JIRA is recommended, and they even manage to sneak in a Confluence mention in a login screenshot. Very cunning! The JIRA mention is actually interesting, because it’s a good example of a fairly insidious tack taken throughout. Whenever there is an alternative to a ‘recommended’ solution, they almost always mention a horrifically bad alternative. The only other issue tracking tool mentioned alongside JIRA is Bugzilla, for example. The IoC alternative mentioned for XWork is Avalon, to ensure xwork is shown in the best possible light.
The XDoclet chapter is also somewhat confusing. For one thing, it seems to go against the choir by giving helpful information about EJBs, and making it clear that EJB development can be made very easy with proper use of xdoclet. Earlier, needless to say, we have the usual EJB disinformation churned out, with furious flailing of arms regarding bad performance compared to hibernate (due to transactions, and security, apparently!), and how even with xdoclet ejb dev is too difficult since the descriptors are not very…human readable. The xdoclet chapter shits all over this theory though as it then shows us how to generate the hibernate xml file and how it’s equally easy to generate ejb descriptors. If the hibernate file is so damn easy and ‘human readable’, why the hell would you use xdoclet to generate it?
To be fair, the xdoclet chapter is one of the few that actually lists pros and cons, instead of the condescending shit-eating grin the other chapters provide, where the powers that be are kind enough to tell us what we should do.
At some point, the book just completely loses the plot and starts telling us about how we should all talk to each other within our teams. I had to rub my eyes a number of times to make sure I wasn’t going blind, they did indeed have a cute little chart that points out synchronous modes of communication (face-to-face!), and asynchronous ones (email! mailing lists!). If you’re the kind of person who needs this sort of advice, you’re hopelessly fucked.
The security chapter gives us some more frantic flailing of limbs; it discusses the downside of custom authentication (difficulty of propagating credentials) but then promptly pretends the problem doesn’t exist.
Then, quite suddenly, the book ends. There’s no wrapup, no conclusion, no gentle let down, nuthin’!
Still, there is one silver lining to this miserable little cloud. The Lucene chapter is well written, educational, and manages to put the ideas across without insinuating that a) the author is a genius, and/or b) the reader is a moron living in a cave. Good job whoever wrote that, you get a belated Christmas pressie of not having to work with the other 3 again. The rest of you, there aren’t enough lumps of coal in the world to punish you for your style and ideas (mostly the lack thereof).
