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

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

[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.

HowTo: How To Deal With A Shitty Book:

[Neil Blender]

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

Re:Interesting pricing

[DogDude]

Well, thank god you can save $2.40! People like you are the reason we have Wal-Mart: a rush to the lowest price with no consideration for any other factor in your purchase. Oh, and I happen to get my books at 75% of the retail price: from an independent local bookstore that actually contributes to my community.

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

[Anonymous Coward]

Trolling for dollars!

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.

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.

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 "[".

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)