Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Iterable Elements

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: "Steve Loughran" <steve.loughran AT gmail.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Iterable Elements
  • Date: Mon, 4 Jun 2007 22:34:34 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page