"there's more than one way to do it"

TMTOWTDI is pronounced tim-todd-ee and it means there's more than one way to do it. I think I picked this up from Programming Perl or Learning Perl. I didn't really learn to program or learn perl, from consulting those books, but I did learn TMTOWDI... which is kind of a problem.
I'm working on a relatively simple task: measure, store and analyze benchmarks for Open Laszlo runtime performance. The problem is that there's so many ways to do it! My thinking started with Java, because most of the OL server is written in Java. Indeed, I implemented the measure-and-store part of the problem with Java Server Pages (JSP). Now it's time for log analysis, and ye gods, Java has been through major honking changes in its support for logging, regular expressions, and XML. There is a surfeit of XML API's for java; in java 1.4 or so log4j-ish behavior became part of the java platform, in java.util.logging; Xerces, Xalan, SAX, JAXB, and JAXP all seem to do pretty much the same thing (parse XML) but Xerces and Xalan were merged into another project, and JAXB and JAXP seem to be just implementations of SAX. Maybe. And how does this all relate to java.util.xml? On the way-back machine that is the WWW, projects from 1999 and Java 1.1 can be nearly indistinguishable from a project from 2006 and Java 1.5. And how can I distinguish between an abandoned project and a project which is so stable that it hasn't needed an update in two years?
...Then the java code that does seem relevant seems to require a heckuva lot of boilerplate. All I want is a bit of regular expression support and math!
That sort of thinking leads directly to perl. Perl has superpowers and was designed for just this sort of task, but I'm not a perl programmer, and I don't want to be. Sorry. Does that make me a bad person? Lazy, maybe: I'd rather spend my time learning and working with a language that I like. I'm not talking fundamental goodness here; I'm talking personal preference. I don't like the idioms of global variables with names like "$_".
Personal preference leads me to Ruby and JavaScript. Ruby, oh you tasty jewel, would be a pleasure to write this log analysis and reporting in -- but ruby is one of the few languages that isn't required by the Open Laszlo tool set yet. A disciplined software engineer wouldn't add a new language requirement to the development environment on a whim. JavaScript would be darn nice, too, especially using E4X, ECMAScript for XML. Is E4X supported by the version of Rhino we use for unit tests in Open Laszlo, rhino 1.5R3? I just spent ten minutes browsing mozilla.org trying to figure this out, and I still don't know. (This feels like what I'll end up doing, though.)
My high school fencing teacher used to say, "don't parade your ignorance" and maybe as a career web programmer I'm hurting my future prospects by confessing confusion with all these API's. So I'll skip rhapsodies on python and bash and XSLT, and just get to the point: TMTOWDI, so let's just get it done! All of these languages and libraries can get the job done, with a complex set of trade-offs between brevity, readability, maintainability, portability, external dependencies, and personal preference. It doesn't matter. Just pick one and get on with it. Stop trying to figure out which one is best; stop trying to grok new technologies while standing in an aisle at Barnes & Noble. What would get me from here to performance benchmark analysis by tomorrow? Straight-up java parsing. Forget XML, just use line-based text parsing with a string tokenizer. Forget object serialization. Forget XSLT. Forget trend graphs of benchmarks over time. Just use plain old text files, and get the job done.
(If I get to producing a simple report with single-number reports on the performance of three different builds, today, then I can play with Ruby while watching Desperate Housewives.)

UPDATE (eight hours later): I wrote the tool that I need in a few hours, using java's StringTokenizer and JUnit. I also went for a walk along the beach and took a nap. Shiny things: IntelliJ IDEA 6 integrated JUnit support. I'm in love with the green bar.