Last night, I came home determined to make forward traction on re-writing a (Java) Swing form to that it is created (with a variable number of fields) on-the-fly based on an XML file. The idea is that the .class file would not have to be regenerated, re-JARed, and re-distributed as the underlying platform evolves. Only fixes (and of course the XML file) would need to be downloaded. That's what I'm trying to achieve in the proof-of-concept anyway.
The roadblock is my complete lack of experience parsing XML in Java--coupled with the fact that I haven't paid attention to that technology niche in many years. The decision to choose a DOM-based model vs. and event-driven model was pretty straightforward. Which means Xerces. Okay, great. I know that I can get download that from Apache--should be a no-brainer. But then I see it mentioned--in passing--that oh, by the way, that's been "bundled" with Java for the last couple of versions at least.
And that's where the annoyance really blossomed. I checked the 1.6 APIs, and those packages are mainly composed of interfaces, rather than classes. Interfaces, in Object-Oriented terminology, an interface is merely a pattern. You (or someone else) has to supply the actual cloth--i.e. the code--to make anything useful. Java Database Connectivity (JDBC) is quite similar in its preponderance of interfaces to classes. But the deal there is that you need a separate piece of code (known as the JDBC "driver") to actually work with a database. Which made me wonder whether I wasn't being misinformed. So there was some time wasted sorting that out.
Once it was established that yes, you could somehow parse XML in Java using Xerces without having to download anything extra (unless you absolutely must have the bleeding-edge version), it next became a question of where the heck do I look for it. Rather than pile everything including the proverbial kitchen sink into one steaming pile o' bytes, Sun--the folks who make the leading Java brand--splits the "extra" features off into separate files. Thees are called JAR (which stands for Java ARchive) files. However, knowing which JAR holds the code you need is the issue. Some--if not most--software development programs install with the bare-bones JARs, however, and you have to manually add in any extras. That was the second, and--as it turns out--the most time-wasting issue.
Because, frankly, trying to find this rubber-meets-road information suuuuuucks. You'd think that the people who invest such sweat into the code they want others to use would put a small fraction of that effort into making installation painless. But nooooo. At least not if half a dozen different Google searches can be counted as evidence of that.
I've forgotten where I read the usability adage, "If you can't click it after three beers, it's too small." But that makes a wonderful baseline for the usability of software in general. And I likewise think that if you can't find the software you want to install in fifteen minutes or less, is it really worth your time? And from the side of the software purveyor--free or not--do you really want your developer's first experience with your product to be one of frustration?
