AspectWerkz's Replacement Libraries

AspectWerkz is becoming one of the more innovative open source Java projects. One striking facet of the projects is its use of equally innovative open source libraries. Let's take a look at some of them and possibly learn something about selecting libraries.

bcel.jar - The ubiqutous bytecode slicer and dicer, however ASM is faster and requires less memory. Although I haven't studied it enough to conclude if its flexible enough. However, cglib folks were impressed enough to make the migration, I wonder if Aspectwerkz is the next adopter.

commons-jexl.jar - For introspection capabilities. I have't compared it to other libraries with similar capabilities. One thought though, an introspection library that's part of a language implementation has got to be tuned for speed, so maybe it was a good choice. Sometimes, you just have to pick libraries based on the kind of applications that use them and you make your inferences from there.

concurrent.jar - Doug Lea's equally innovative library for handling concurrency. No other worthy competitor.

dom4j.jar - A much better choice than the perennial beta JDOM. DOM4J allows replacement of underlying tree model, in fact it has one built-in that's reasonably space efficient. See "Slaying the XML Behemoth".

jisp.jar - Interesting, there are alternatives like JDBM that Rickard Oberg seems to like better. Also Netbeans has a btree database that was developed by Forte.

jrexx - Regular expression library. Aspectwerkz doesn't need the full power of a NDFA. So choosing a high speed DFA based one is a good choice. See "Regex Benchmarks".

piccolo.jar - High speed XML parser built using parser generators. Hard to beat a code generated parser. See "Faster XML Parsing".

qdox.jar - High speed doclet like engine. Unlike xdoclet that builds an Abstract Syntaxt Tree (i.e. AST) for everything, qdox parses only relevant parts and ignores everything else.

trove.jar - Hand optimized collection classes for primitives. I guess sometimes you need to squeeze out every juice of performance you can get.

Sometimes you can tell the quality of a project on what library it uses. AspectWerkz has made a couple of excellent choices, and I look forward to seeing the other choices they make in the future.

I'm also glad that they got rid of JMangler, its inclusion always puzzled me, however sometimes you have to be expedient. That leaves me with one last lesson, when in a rush, just pick whatever works today, don't reinvent it. Only when you gain enough experience to know the tradeoffs, then that's when you can work on a "reinventing" replacement.

Interestingly enough, ASM, JRexx, Piccolo, qdox and trove are replacements of existing well known libraries. They're all faster than what they've replaced but that's because their functionality is more restricted. It takes experience to make the tradeoff between functionality and performance. I can hear echos of "Premature optimization is the root of all evil" and "Refactor mercilessly".