Gary Gregory

Senior Software Engineer

Seagull Software





From: Michael Glavassevich []
Sent: Thursday, July 08, 2010 10:33
Subject: Re: [POLL]: Dropping JDK 1.3 support for Xerces-J?


Hi Jake,

"Jacob Kjome" <> wrote on 07/08/2010 12:58:49 PM:

> I have a library I develop (XMLC [1]) that depends on JDK1.3 and also depends
> on Xerces.  That said, part of the reason of depending on JDK1.3 is
> to stay in
> line with the Xerces dependency on JDK1.3.  The other reason is thatJDK1.3 is
> free and clear of any built-in XML APIs, which allows me to include exactly
> the JAXP library of my choice (xml-apis.jar) without worry of compile-time
> binding to odd invalid APIs included in 1.4 (such as some stuff meant for the
> HTML2 API that got placed in the HTML1 API DOM package namespace).  But if
> Xerces decides to move to a later version of Java, then I will probably move
> XMLC right along with it.
> That said, I would think that if Xerces were going to bother making a move at
> all it would move to JDK1.5 rather than bother with 1.4.  Xerces 2.10 is
> always there for 1.3 and 1.4 codebases, which should all be well into
> maintenance mode meaning few, if any, library changes.

It's often not a choice but a constraint of the environment the developer is working in, having to write a new application on top of a product stack which is stuck on one of these earlier JDK releases. JDK 1.4 isn't dead yet; still in service for some vendors, including Oracle/Sun if you're a business willing to pay for the support. Not aware of any vendors supporting JDK 1.3 anymore though.

> Moving to 1.5 would
> allow Xerces to take advantage of all the new language constructs added in
> 1.5, as well as APIs added in 1.5 (e.g., StringBuilder -vs- StringBuffer).

Right. We all talked about the benefits of moving up even higher to Java 5 and 6 before, but have been quite conservative about upgrading because of where we are in the food chain.

This seems like some harsh handcuffs for Xerces to live with. If an app is stuck on Java 1.3, is it also evolving and keeping up with Xerces versions and new XML and XML Schema standards? As argued above, you can always use Xerces 2.10, forever. Why not lose the shakles? What about getting started on Xerces 3.0 with a 6 requirement and maintain Xerces 2.x on Java 3 with critical bugs fixes only? And say “Welcome to the 21st century J



> So, +1 for changing JDK dependency in general, but I would prefer a move
> straight to JDK1.5+ skipping JDK1.4 support.  This also seems to be
> what a lot
> of Apache commons libraries are doing, so it's certainly not unprecedented.
> [1]
> Jake
> On Thu, 8 Jul 2010 11:36:07 -0400
>   Michael Glavassevich <> wrote:
> >
> >
> > Hi all,
> >
> > (including on the cc list to hopefully reach a wider
> > audience)
> >
> > We're talking again on the Xerces j-dev mailing list about dropping support
> > for JDK 1.3. The reason being that current builds of the XPath 2.0
> > processor (Eclipse PsychoPath) used by the XML Schema 1.1 implementation
> > require JDK 1.4. While we do have a one-off PsychoPath jar that was built
> > with JDK 1.3 some time ago, in order to pick up recent bug fixes in this
> > library we need to refresh it with the JDK 1.4 version. This would only
> > impact the XML Schema 1.1 enabled release for now but at some point in the
> > future when XML Schema 1.1 becomes stable (both spec and impl) this would
> > get merged into the main line.
> >
> > Given the age of JDK 1.3 and that it's generally out of service my
> > intuition is that this upgrade would probably be okay but wanted to check
> > with users on their needs. Is there anyone out there still using Xerces-J
> > with JDK 1.3? If you are, how long into the future will you continue to do
> > so, and would you be willing to migrate to JDK 1.4 (or higher) to be able
> > to use XML Schema 1.1?
> >
> > Thanks.
> >
> > Michael Glavassevich
> > XML Parser Development
> > IBM Toronto Lab
> > E-mail:
> > E-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


Michael Glavassevich
XML Parser Development
IBM Toronto Lab