Wednesday, August 06, 2008

Jackson JSON-processor: winning over "customers", one by one

I was delighted to find out this little gem of a blog entry. Not just (or even so much) due to author having good things to say about Jackson JSON processor (standing out over multitude of ostensibly similar alternatives), but because I can relate to the challenge of evaluating multiple freely available alternatives.

I like it when I see other people taking their time actually figuring out best (or good enough) tools: not only should that be good for the individual and their immediate surroundings (team, company), but in the end I think it is also essential for the health of "Open Source ecosystem". Without selective customers there will not be much evolutionary forces, and the only significant system of feedback will be amplification for the most popular systems.

Also, although I do not have a good idea as to how many users (or, groups of users) of Jackson there are (most often I learn of new users via feature or bug reports -- based on this, I would estimate it to be in "at most a dozen" range), I know that for now adoption happens by winning potential users over, one by one. And I actually like it: early adopters use libraries either because they have no alternatives, or because they have found them best for their use. I prefer this over just getting new users because of existing users, inertia, and general ignorance of developer population. So if Jackson had a motto, it could well be adapted from Hertz' slogan: "We are just one of 17 choices, so we work harder!".

Monday, August 04, 2008

"Kooderin Pienet Ilot" (or: Big Joy for a Small Fry)

Ok.I must admit that while this is an extremely tiny step for the humankind, I feel disproportionate pride for it: turns out that I made my first mark on JDK (version 1.6.0_07)! (for comparison, my 4 year tenure at Sun did not lead to a single dent in JDK) This was achieved by reporting bug 6620632 (originally Sjsxp bug #48), proposing a patch, and by some stroke of luck having someone see it fit to include it in a patch-level update. So what is the bug about? DTD events for Sun's Stax parser do not include notation or entity information, even though it is readily available -- caught by StaxTest test suite I have written, and ran against Sjsxp.

Yay! Hey, where's my resume again, I gotta add a reference... maybe right above notes about my college degree and below summary of my work experience... :-)

I need to get a life. And soon!

Friday, August 01, 2008

StaxMate 1.2 released: support for Sjsxp, Aalto

I released StaxMate 1.2, and as mentioned earlier, it will now fully support Sun's SJSXP Stax parser. As an added bonus, it will also support ultra-fast Aalto parser.

After having made this interim release, I decided to document my ideas for the next release at Codehaus StaxMate Jira. Turns out that many cool ideas do NOT require waiting for the next revision of Stax2 (which comes with Woodstox 4.0). Ideas that seem most useful, based on my recent usage of StaxMate include:

  • Support for JAXB; for reader-side it means traversing super-structure (second-level elements below root etc) using StaxMate, and binding individual sub-trees with JAXB. That seems like a very convenient and efficient way to process data-oriented xml.
  • Making StaxMate input and output factories instantiable, giving underlying stream input/output factory, and allowing construction of both StaxMate cursor/output object and matching stax stream reader/writer, instead of having to do these separately.
  • Typed write methods: there are couple of existing reader-side method, but I have actually needed writer-side methods more often than reader-side ones.
  • Ability to construct cursors from event readers, not just stream readers.

For others it may be that DOM/JDom interoperability might also be quite handy, although I have so far managed to avoid needing these.



Related Blogs

(by Author (topics))

Powered By

About me

  • I am known as Cowtowncoder
  • Contact me at@yahoo.com
Check my profile to learn more.