XOM API for Processing XML with Java

["Steve Loughran" <steve.loughran AT gmail.com>]

On 01/06/07, Michael Kay <mike AT saxonica.com> wrote:
> > you are unwilling to pay the onerous
> > entry ticket to the enterprise software world; I assume
> > Elliotte's position is much the same.
>
> No, that's not how I would put it. So called enterprise software tends to
> hold customers back; they're stuck on JDK 1.4 or earlier because they are
> using some application server or database with a 6-figure price tag that
> contains a zillion lines of code and only produces a new release every four
> years because it's impossible to test the bugs out, and which doesn't work
> with JDK 1.5 because for all those megabucks, the vendor can't actually move
> very fast. The reason I don't want to play that game is because I don't
> think that's the kind of software that enterprise users actually want: they
> want something that's cheaper, smaller, leaner, and more fast-moving. When
> they can get that, they are prepared to move forward when necessary to fix
> bugs.
>
> I've got plenty of users, both paying and non-paying, doing serious
> enterprise things with Saxon, and I'm sure the same is true of XOM. Often
> they are using much older releases than is healthy. For a paying customer I
> would certainly consider fixing an old version where necessary. But until
> now it has always been the case that if when a user hits a problem with an
> old release, the best solution has been to move forward, and I would much
> rather put effort into making it easy to move forward than to start
> maintaining old releases, because I think that's in the best interests of
> all my users. If they have to forgo some fancy (and largely cosmetic) new
> feature in JDK 1.5, that's a price worth paying.

This is a really interesting discussion.

At work our core codebase is all Java 1.4, with various compnents java
1.5, because some of our partners havent upgraded yet, and we can't
force them to. it makes things hard, but once the next release is out
we will say 'java1.5+ only', and add some java1.6 extras on the side.
The benefit isn't really generics, its concurrency, a valid memory
model and the possibility of fixing the proxy code. the rest of
networking is still a mess, especially on a laptop, but its a start.

In my spare time, over on Ant, we have just abandoned Win9x and
Java1.2. Why? Because it is not the job of the build tool to force an
upgrade. Java1.2 was dropped because sun abandoned it, and win9x
because not only was it too insecure to even bring up a vmware image
of the OS, everyone hated bugreps related to the .bat file. those 50
lines of code were too high a cost.

That's one of the OSS advantages, you can offload maintenance costs to
the end users "we no longer support win9x, here is the old .bat file".
The other is that you can respond to most bugreps with the query "does
it work in the latest build"?

that question does a number of things
-sees if it really matters to them
-forces them to download and build the app/lib, which is the first
step to patching it.
-sees if the problem has been fixed
-finds any regressions of SVN_HEAD on their system
-sets them up to start patching it.

Once you branch, you can't do that any more, and you end up taking on
all testing/fixing/patching costs yourself.

Java 1.5 is probably the biggest change to the language since inner
classes; generics, enums, tags and the like are a one way transition
-and make old code seem dated. This is more obvious for collection
datatypes that you can walk over (like Xom graphs) than other things.
It can break a lot of stuff too...which is why the transition to Java
EE 5 has been so very slow. There is still a lot to be said for
utility libs to stay in the 1.4 world, unless the jump to 1.5 is so
compelling that it benefits everyone, developers and users. EJB3?
Justified. JUnit 4? Not so good. Xom? Maybe.

-steve