Jive Software has released a Jabber API for Java into the public domain. It
is called Smack and one thing that struck me was that this library
doesn't depend on any other XML library. In other words, they
rolled their own XML parser.
Normally, I wouldn't recommend that, as what you loose in performance
considerations with dealing with XML in the first place you gain in
development time by using already built parsers.
However, in this case, Jabber… er XMPP, is kind of strange in
that it doesn't transfer XML documents but XML streams. Sure, this
clearly means that DOM is not a good approach, but why isn't SAX? While I
haven't talked to the Smack developers, my guess is that Jabber has some
obvious use cases that could be optimized by parsing it directly instead of
using the SAX approach.
Thoughtful Consideration better than any Pattern
I was reading the latest issue of Java Performance Tuning and noticed
an interview with Bill Lynch and Matt Tucker, who founded Jive
Software, and they make some interesting points in regards to design
considerations and performance.
What struck me the most was their "thoughtful consideration" of all aspects
of their programs. For instance, even though their requirements stated that
they needed to be scalable across clusters, they didn't just choose EJBs--
they answered the requirement.
They also just didn't use standard caching software since they could see
their own usage patterns and could gain significant performance
improvements by rolling their own.
This is the balance that we all need… between building upon more
generalized code (for quicker development and that has usually been
better-tested) and creating unique, specialized solutions for performance
reasons. It just goes to show that thoughtful consideration is better than
the thoughtless application of any design or architectural pattern.
Still looking for a rule? Try this one for size… start with general
building-blocks but keep things transparent and your components loosely
coupled. Then start looking for usage patterns, bottlenecks, and better
implementations and start re-factoring.
I also think that there is a business case for this approach. Your customer
gets what they want on time (since you built your code upon the shoulders
of other software) and they are willing to pay for performance
Tell others about this article: