Apache Jakarta Commons

Simon P. Chappell writes "This is a hard review to write because I feel that I should be biased in favour of this book. I was one of the original reviewers of the book proposal. I read it and said "Yes, they'll be lining up around the block for a book like this!" Well, maybe those weren't my exact words, but I did offer my endorsement. After all, the Jakarta project of the Apache Software Foundation has an excellent reputation for quality Java code products and the Commons is quite the supply of diamonds in the rough. What could go wrong?" Read on for the rest of Chappell's review to find out. Apache Jakarta Commons - Reusable Java Components author Will Iverson pages 338 (8 page index) publisher Prentice Hall rating 4 reviewer Simon P. Chappell ISBN 0131478303 summary There are other books about the Jakarta Commons; buy one of those instead.

What's To Like

The book takes the reader on a journey through the Jakarta Commons. The Commons is like a massive utility library of Java code. Much of the code has been promoted out of the other Jakarta projects as it became more useful. One of the first such components was the Digester, which is a component to initialise a Java object from the contents of an XML configuration file. Very useful, originally from Struts and now used extensively by other Jakarta projects.

As the subject matter for a book, the Commons seems like a natural winner (I guess I have to say that!). There are so many components in the Commons that a guide to their types and usage does need to be available for developers.

Naturally, the book has a website to accompany it.

What's To Consider

Where to begin? I was actually surprised to find that I did not care for this book. The last review I wrote was for Mr. Iverson's very good Hibernate book. That was well written and structured. Unfortunately, this book feels kind of thrown together. The lack of care shows in the cramped layout and typesetting, the over-abundance of UML diagrams (a few here and there are great, but this felt like padding), code examples that can only be described as under-whelming and an approach that feels like an annotated telephone directory.

Despite the lack of quality of the primary chapters, they only actually account for the first 199 pages of the book. This is actually a very reasonable number of pages for a book, especially when you consider that classics like the first edition of Kernighan and Ritchie's "The C Programming Language" weighed in at about 220 pages. Sadly, the book then goes on for another 125 pages churning out what looks like repackaged JavaDoc for each of the major classes in the commons. You may like this, but it annoys the beans out of me and it'll reduce the score on one of my reviews faster than the Linux community can debunk a SCO IP infringement claim.

Summary

I really wanted to like this book. But it feels like someone was cranking the handle on a cash machine and thought that if they printed stuff about Jakarta, that the geeks would obediently buy it. Not this time. There are other books about the Jakarta Commons; buy one of those."

You could purchase Apache Jakarta Commons - Reusable Java Components from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Interesting pricing

[AKAImBatman]

If you go through the Barnes & Noble link for the book, you'll find that the book costs $31.99 for the unwashed masses, and $28.79 for the "B&N members". What Barnes and Noble isn't telling their members is that they are still paying more than if they went to Amazon! Even with an associate laden link, you can still get the book off of Amazon for a mere $26.39! And no membership hassles to mess with!

From an Amazon review:
Note that this 325-page book is really a 201-page book. Appendix A is the entire API of the Commons lang project - word for word.

Am I the only one who gets annoyed at how computer books have devolved into hardcopies of auto-generated online documentation? Am I the only one who remembers books that cover the intangables of coding (e.g. theory of operation, correct methodology for usage, cool coding and hardware tricks, etc.) rather than the "instruction manual for dummies" books? Bah, I say! I don't know which is scarier: the current trend in books, or the fact that the review I'm citing gave the book 4 out of 5 stars.

Of course, I'll probably get in trouble with my fellow authors for saying this. (Sorry guys, but I just don't like 90% of the books being printed.)

Re:Interesting pricing

[grahamlee]

The first time I really got annoyed by this sort of thing was back when I was learning NeXTSTEP programming. Their developer reference docs were largely a hardcopy set of API regurgitations, but this was OK because they were well indexed (as they bloody well should have been, I expect they were just printouts of the NeXT Librarian format online documentation). I also don't mind this because for really ploughing through a book, I still prefer dead tree to online format[*]. However, the printed documentation for the compiler/linker/debugger toolset was just a troff-formatted pretty version of the GNU manpages (remember this was back when RMS didn't mind man too much). That really annoyed me. They were badly indexed, containing the same information as a manpage in the same linear style and without the utility of a content search.

[*]This is why I own a number of books in both online (for quick reference) and hardcopy (for actually studying) formats, even though the online version is free (c.f. Numerical Recipes, the X manuals, some of the Perl books etc.)

Re:Interesting pricing

[TrappedByMyself]

Or get it even cheaper at Bookpool for $25.50

Re:Interesting pricing

[the_rev_matt]

You shouldn't be worried about the 4 star rating. It's out of 10.

Re:Interesting pricing

[jc42]

Hemp produces more pulp per acre than timber on a sustainable basis, and can be used for every quality of paper.

A couple of years ago, there was a book written on the history of the US drug laws. I've forgotten the book's (or author's) name, but he documented an interesting "coincidence": The campaign to outlaw cannabis/marijuana/hemp was basically done by the Hearsts. They owned a large amount of land that was mostly pulpwood farms. Just before the anti-marijuana campaign started, a new hemp-to-paper process was patented that produced paper at half the cost of the cheapest wood-based process. This essentially made the Hearts' pulpwood farms useless. They responded by bankrolling the anti-drug campaign, including lobbying Congress to include the Evil Weed in the list of drugs.

It never did make sense that such a mild euphoric would cause such a wildly off-scale response, until someone dug up the above history. Then it all made sense.

Pulpwood farming is still an industry in the US. And it's almost all big corporate farms. We know the attitude of the current Congress towards corporations, of course. So we can't expect any serious change in the drug laws any time soon. Not unless some major hemp growers start making a lot of campaign contributions.

A number of articles have been published recently discussing the statistics showing that most of the increase in drug arrests in the US over the past 15 years or so has been for marijuana. Some of these articles have mentioned that hemp is potentially a serious threat to big American tree-farming interests. But the articles I've read haven't actually explained the connection.

Content-free review

[winkydink]

This has to be among the worst booke reviews I have ever seen on Slashdot. And that's saying something. Most reviewers take the time to give you some detail. An indication of whether or not this book is for you. This just seems like a shameless whoring to get affiliate credit with B&N under the guise of a book review.

Re:Content-free review

[ch-chuck]

The above review of the book review was, altho short and concise, informative and to the point. Altho the conspiracy theory nature of the final remark went perhaps a little too far, considering the off-the-cuff source and likelyhood of going for 'first-post' status, it is worth at least an 'interesting' moderation.

Re:Content-free review

[harrkev]

This just seems like a shameless whoring to get affiliate credit with B&N under the guise of a book review.

I might be inclined to agree with you had he actualy said that the book was worth buying, which he didn't. As it is, an affiliate link does not bother me.

Re:Content-free review

[Ziviyr]

Indeed, at first I endorsed this review, but upon reviewing said review, I found I did not like it.

This review definitely feels kinda thrown together.

HowTo: How To Deal With A Shitty Book:

[Neil Blender]

Stop reading it the minute you realize it's shit.

Review, or Oscar acceptance?

[lheal]

Next time, spend less effort writing about your own involvement and more time on that of the authors of the book.

Associate-free link

[Anonymous Coward]

Even with an associate laden link, you can still get the book off of Amazon for a mere $26.39! And no membership hassles to mess with!

Or you can use the non-associate link to prevent datadino's flagrant commission-whoring.

Hey! buy the Jakarta Commons Cookbook

[BigTimOBrien]

:-)

I wrote a book on the Jakarta Commons - The Jakarta Commons Cookbook, and, from what I hear people like it. Really, you should read it, I tried to stay as far away from reference as possible and pack it full of useful recipes.

Re:Hey! buy the Jakarta Commons Cookbook

[greg1104]

Amazingly, this bit of self-promotion is actually more useful than the review. Tim O'Brien's book is my favorite on this subject and it's far, far better than the Will Iverson title. I particularly like how well it covers some of the extremely useful but not well documented APIs like the HttpClient, there are far more readable, usable examples that cover the kind of real-world issues you run into the minute you try to use that API than any other source I know of.

Larne Pekowsky: "Apache Jakarta and Beyond: A Java Programmer's Introduction" is also a decent title in this area, albeit a bit too broad to really do that good of a job on any topic. Even a 600 page book can't cover things like Eclipse or Ant in a chapter.

I have all three books on my Safari bookshelf right now; only O'Brien's is staying once I can remove the other two. The Iverson and Pekowsky titles have some interesting sections worth looking at once, while "Jakarta Commons Cookbook" I always want to keep around for reference, in the same fashion I already rely on the similarly useful "Java Cookbook".

Re:Hey! buy the Jakarta Commons Cookbook

[rjshields]

I love cookbooks because they show you creative ways to use the library to solve real problems. The code snippets given get you up and running with a library almost immediately, as you have a working piece of code to use as a starting point for solving your own problem. Contrast that with writing code against a new library from scratch and you'll find a great learning aid and time saver.

If I want to read the API docs, I'll go to the Jakarta Commons website and read them. I don't want to waste money and trees on API docs used to pad out a book!

I haven't read the Jakarta Commons Cookbook yet, but it's on my reading list.

Re:Hey! buy the Jakarta Commons Cookbook

[symbiontnet]

I would recommend everyone to O'Brien's Commons Cookbook. It is concise and to the point, (as a good cookbook title should be), with lots of good summaries and examples.

He gives just enough attention to a topic to give the intelligent reader the gist, as well as a jumping-off point for further investigation into the specific commons sub-project.

I was familiar with and actively used several commons components before, but this book introduced me to many I was not even aware of (or was aware of but didn't completely understand what it would be useful for). Also gave me ideas for how to easily integrate new commons packages into new projects under design for a tighter and more efficient architecture.

Go get it now...

Why might it be better than the free docs?

[Soong]

I think that's the first question any book like this would have to answer. Free and reasonably comprehensive documentation is included right along with all of these libraries. Why pay for anything more?

The answer is likely to be in tutorials or teaching narrative. I bought the OpenGL Guide for that to learn OpenGL because the API was a nasty maze to navigate otherwise. I don't think Jakarta Commons have that problem and I don't expect I'll be buying a book about them.

Re:(OT) Request: Help From Moderators

[MynockGuano]

This is like punch the monkey, Slashdot style.

Please mod down these peo--WHACK
Why don't you spend your mod poin--SMACK
Can't you see that you're all being very unreaso--POW
OMG WTF STOP IT YOU STUPID IDIO--THWACK

whatever

[fkamogee]

Call it a troll if you want, but this is what I really think.

1) Commons is way overrated. A lot of the code is not great if you dig into it, and generally the components solve very small problems. Often, you're better off doing it yourself than adding a volatile dependency to your project.

2) There are some worthwhile components in Commons, but that does not imply that that the same quality or usefulness can be assumed of the other components. Same goes for the rest of Jakarta. And the rest of ASF.

3) Those Commons components that are good seemingly get used by everybody, resulting in versioning conflicts between your various third-party libraries. Which is fun because the API's are unstable, and because the project maintainers sometimes fail to maintain either compatibility or mutual exclusion between releases. This happened with the Collections component.

4) Seriously, OP, you thought this would be a great book? What is there to offer in a book that's not online? And considering the instability of these packages, how long is that book going to be relevant?

Re: Whatever

[SlightlyOldGuy]

So I should write all this stuff for myself? Really? No thanks. Some of the Commons components are annoying, but not as annoying as my done-under-deadline versions. If your stuff is so wonderful, perhaps you might consider contributing some of it? hm?

Re:whatever

[Anonymous Coward]

First, I'll declare my bias. I'm a maintainer for one of the commons projects.

re (1): There are very few (if any) projects in commons that haven't taken at least 6 man-months of development time. If you do only want a very small piece of the functionality of one project, then maybe you're better off doing it yourself but generally I think reusing the existing code *does* provide significant time savings.

re (2) Well, that's probably true of code anywhere. But code doesn't get into commons unless it's being used by some project.

re (3)
In order to improve software it is sometimes necessary to change APIs - but that only ever happens on major version changes (eg collections 2.x to collections 3.x). Commercial packages do the same thing. Yes, it can be a nuisance, particularly as the poster said when building a large project where multiple other components depend upon commons too. Suggestions for solutions to this issue are very welcome!

Note that due to the APL license you are free to take the commons code, and put your own package names on it. That way, you get the commons code but with no version dependency issues. Of course you can't easily integrate fixes to the original package into your "forked" version. This still has to be better than writing the code yourself though (and don't forget those unit tests and javadoc!).

re (4): Major number revisions of important commons components happens fairly rarely. And of course as the components get more mature it happens less. I can't see collections making a non-compatible change again for several years (if ever). And even in a major-number revision, only a small part of the API is likely to change. That's not going to obsolete either a book or a user's knowledge of the component.

Where's the review?

[Augusto]

And what does rating (4) mean? (4 out of what?)

What are the other books that are better? Why?

What is the "Jakarta Commons"? I know what it is, but you'd think the review will explain this briefly and then say how the book failed or succeding at explaining them.

I give this review a rating of "[".

FYI From The Author

[will_iverson]

I would just like to respond to the bit about "cash cow":

1. The book itself is published under an open license - the material in the book will be available as a free electronic download in a few months.

2. Yes, the last 125 pages *is* (for all intents and purposes) the printed javadoc. This was included at the request of the publisher, and it is valuable for some people.

So... I don't know how negatively the review was influenced by the inclusion of the Apache material, but it is entirely above-board per the Apache license and essentially reciprocal - I'm giving the material in the book back to the community via a free license to download the material.

Oh, and as an FYI, book writing is hardly a cash cow - I only wish. ;)

If folks have any questions (e.g. why the delay in making the electronic version available? What is the state of affairs for tech book publishing? Why aren't you rich writing books yet?) let me know...

Cheers & best wishes,

-Will Iverson

good to hear no javadocs

[steve_l]

I'm glad you dont have javadocs. Its a cheap way to make a bad book.

more to the point, it dates so fast in the OSS world. Oreilly could get away with the original Java in a Nutshell book because the entire Java API was small enough to print, and because the API stayed frozen for two years.

but any living OSS project has an API that evolves weekly; and point releases every few months. printed documentation just doesnt cut it here. Instead books have to focus on why and how to use library, not what the APIs are.

I know that is actually harder, but the reader benefits, and so ultimately, the author and publisher.

-steve

(currently writing the second edition of Java Development with Ant)