XML support in Java 5?

[Peter Duniho]

The javax.xml and javax.xml.stream packages have some classes that look
very useful for writing and reading XML (the latter package especially).
Unfortunately, as near as I can tell they are for the most part only
supported in Java 6 and later. The few things that are documented as
being in Java 5, I don't see how they are useful for actually writing XML.

The XMLStreamWriter and XMLStreamReader classes are the ones in particular
that I'd find useful. But I need something that doesn't require Java 6.

I can write a simple implementation myself for my own purposes. What I'm
writing isn't very complicated and I can get by without a full-fledged
XML-compliant class. But I'd just as soon use a built-in class if there
is one.

I've searched the Sun docs every way that I can think of, but the only
thing that turns up each time are the Java 6 classes. The closest thing I
could find is a writer in the SQL package, but it doesn't seem appropriate
for my use (there's no database involved here).

Is there any simple XML support in Java 5? If so, can you please point me
to the appropriate class name or documentation page?

Thanks!
Pete

 

[Arne Vajhøj]

The javax.xml and javax.xml.stream packages have some classes that look
very useful for writing and reading XML (the latter package
especially). Unfortunately, as near as I can tell they are for the most
part only supported in Java 6 and later. The few things that are
documented as being in Java 5, I don't see how they are useful for
actually writing XML.

The XMLStreamWriter and XMLStreamReader classes are the ones in
particular that I'd find useful. But I need something that doesn't
require Java 6.

I can write a simple implementation myself for my own purposes. What
I'm writing isn't very complicated and I can get by without a
full-fledged XML-compliant class. But I'd just as soon use a built-in
class if there is one.

I've searched the Sun docs every way that I can think of, but the only
thing that turns up each time are the Java 6 classes. The closest thing
I could find is a writer in the SQL package, but it doesn't seem
appropriate for my use (there's no database involved here).

Is there any simple XML support in Java 5? If so, can you please point
me to the appropriate class name or documentation page?

The XML stream stuff is what is known as STaX. It became standard
as part of Java 6, but you can get STaX for older Java versions
as well.

One implementation is here:
http://stax.codehaus.org/Download

Reading XML has been part of Java since version 1.4 - you can choose
between W3C DOM and SAX.

One of the weird things about the Java W3C DOM is that it does
not have something simple to output XML.

You can use XSLT or my preferred solution: the XMlSerializer
class that comes with Xerces and also exist in SUN Java.

I have lots of coding examples of W3C DOM, SAX, JDOM, XMLSerializer
etc. - just say what you want and I can post something.

Arne

 

[Arne Vajhøj]

The XML stream stuff is what is known as STaX. It became standard
as part of Java 6, but you can get STaX for older Java versions
as well.

One implementation is here:
http://stax.codehaus.org/Download

Reading XML has been part of Java since version 1.4 - you can choose
between W3C DOM and SAX.

One of the weird things about the Java W3C DOM is that it does
not have something simple to output XML.

You can use XSLT or my preferred solution: the XMlSerializer
class that comes with Xerces and also exist in SUN Java.

And then there are also JAXB and the XMLEncode/XMLDecode that
has existed since 1.4.

Arne

 

[Peter Duniho]

Thanks for the suggestions. My thoughts...

The XML stream stuff is what is known as STaX. It became standard
as part of Java 6, but you can get STaX for older Java versions
as well.

One implementation is here:
http://stax.codehaus.org/Download

I'm looking for something that would already be in the JRE. If I'm going
to deliver any XML implementation along with my application, it's going to
be a bare-bones one I wrote myself. I don't really even need this to be
XML...I just like XML because it's a little more readable.

Reading XML has been part of Java since version 1.4 - you can choose
between W3C DOM and SAX.

Okay, I see org.xml.sax, with some reader-like things. I assume that's
what you're talking about with SAX. I also see org.w3c.dom.

One of the weird things about the Java W3C DOM is that it does
not have something simple to output XML.

Just looking at the API, it would _seem_ like the DOM packages would be
useful to me. Manipulating an XML document looks very easy. Constructing
a Source and Result for use with a Transformer is also very easy. And as
near as I can tell, I can go both ways.

Unfortunately, I'm having trouble getting a DOMImplementation. The most
reliable technique (at least in my environment) appears to be to get a
DocumentBuilder instance and use that to retrieve the DOMImplementation.
But when I look at the class it returns, the package
(com.sun.org.apache.xerces) isn't one I recognize from the Sun Java docs,
which makes me wonder if I can really count on it being installed in any
Java 5 run-time implementation.

This technique actually involves the least lines of code of the ones I've
looked at. Serialization might be shorter if the data I'm trying to save
out to a file were encapsulated in a class designed for serialization.
But it's not. So using the XMLEncoder/XMLDecoder from the XML
serialization requires additional retrofitting work to allow my code to
work with it. I'd rather just use the DOM stuff if I can be assured that
it's portable.

If it's not, then maybe XMLEncoder/XMLDecoder is in fact the best solution
given the Java 5 restriction. That seems certain to be in any Java 5
implementation.

You can use XSLT or my preferred solution: the XMlSerializer
class that comes with Xerces and also exist in SUN Java.

Xerces is the name of the package I didn't recognize above. If I can
count on it being standard in Java 5, then either the DOM approach or
using the XMLSerializer you mention could be a useful approach. But if
not, it's not suitable for my needs. Is it standard in Java 5?

I have lots of coding examples of W3C DOM, SAX, JDOM, XMLSerializer
etc. - just say what you want and I can post something.

Well, writing the code isn't the hard part. Knowing where to look for the
general API I need to use is. Also knowing what's standard in Java 5 and
what's not is difficult. My assumption is that if it's not at
http://java.sun.com/javase/6/docs/api/ then it's not part of the standard
Java (and of course, if it's listed there but is "Since 1.6", it's too
recent for my needs). So I appreciate the offer of code, but what I
really need is a map to navigate the various APIs to know which ones are
actually potential solutions or not, based on their portability.

Pete

 

[Peter Duniho]

[...]
Just looking at the API, it would _seem_ like the DOM packages would be
useful to me. Manipulating an XML document looks very easy.
Constructing a Source and Result for use with a Transformer is also very
easy. And as near as I can tell, I can go both ways.

Okay, I got this working. Except for one little problem: the StreamResult
I created isn't using any whitespace to format the XML. This doesn't
prevent the XML from working, of course, but it does negate much of the
readability I was hoping for in using XML in the first place.

With the DOM API, is there any way to tell it to format the output with
newlines (and as a bonus, with indentation)? I've used other XML
implementations that provide this as a simple boolean property on the
output class instance. But I can't find anything like this in the
StreamResult class, or even in the other related classes.

Pete

 

[Greg R. Broderick]

[...]
Just looking at the API, it would _seem_ like the DOM packages would be
useful to me. Manipulating an XML document looks very easy.
Constructing a Source and Result for use with a Transformer is also
very easy. And as near as I can tell, I can go both ways.

Okay, I got this working. Except for one little problem: the
StreamResult I created isn't using any whitespace to format the XML.
This doesn't prevent the XML from working, of course, but it does
negate much of the readability I was hoping for in using XML in the
first place.

With the DOM API, is there any way to tell it to format the output with
newlines (and as a bonus, with indentation)? I've used other XML
implementations that provide this as a simple boolean property on the
output class instance. But I can't find anything like this in the
StreamResult class, or even in the other related classes.

I do this using the setOutputProperty() method on the Transformer object:

TransformerFactory tFactory = TransformerFactory.newInstance();
Transformer transformer = tFactory.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");
transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-
amount", "4");


Cheers!
GRB


--
---------------------------------------------------------------------
Greg R. Broderick (e-mail address removed)

A. Top posters.
Q. What is the most annoying thing on Usenet?
---------------------------------------------------------------------

 

[Stanimir Stamenkov]

Mon, 28 Jan 2008 21:02:53 -0500, /Arne Vajhøj/:

The XML stream stuff is what is known as STaX. It became standard
as part of Java 6, but you can get STaX for older Java versions
as well.

One implementation is here:
http://stax.codehaus.org/Download

I've seen there's ongoing work to add StAX to Xerces2 but I don't
really know when it will be available in it.

Reading XML has been part of Java since version 1.4 - you can choose
between W3C DOM and SAX.

One of the weird things about the Java W3C DOM is that it does
not have something simple to output XML.

Have you tried the DOM Level 3 Load and Save API [1]? As far as I
see it is part of the Java 5 API [2] and is available for Java 1.4
users through plugging the Xerces2 library.

[1] http://www.w3.org/TR/DOM-Level-3-LS/load-save.html
[2]
http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/ls/package-summary.html

 

[Stanimir Stamenkov]

Mon, 28 Jan 2008 17:45:25 -0800, /Peter Duniho/:

The XMLStreamWriter and XMLStreamReader classes are the ones in
particular that I'd find useful. But I need something that doesn't
require Java 6.

I can write a simple implementation myself for my own purposes. What
I'm writing isn't very complicated and I can get by without a
full-fledged XML-compliant class. But I'd just as soon use a built-in
class if there is one.

I can't advise you more than using a library which implements the
interfaces, like Arne already did, but at least XMLStreamWriter is
easily implemented over the standard Java 1.4 transformation API and
implementation, using an TransformerHandler [1] which basically
provides SAX API to generate a result as opposed to parse an input
using SAX. I've done simplified version for my needs time ago and
its inner workings are the same as this example:

<http://mail-archives.apache.org/mod...s/200801.mbox/<[email protected]>>

As for XMLStreamReader - it could be implemented over a SAX
implementation too, but the implementation must use two threads and
the penalty of synchronizing them is too much over the benefit of
ease of use. One could also implement it using the Xerces2
pull-parsing interface, but as you want it pretty much
out-of-the-JRE-box everything I've written here is only as
"interesting to know".

[1]
http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/transform/sax/TransformerHandler.html

 

[Peter Duniho]

I do this using the setOutputProperty() method on the Transformer object:

TransformerFactory tFactory = TransformerFactory.newInstance();
Transformer transformer = tFactory.newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");

Ah, much better. I actually wrote a little custom Writer class to wrap
the Writer I was actually using for the StreamResult. It inserts
whitespace as necessary between XML tags. That did the job, but this is
obviously much better. Thanks for the tip!

As for this one:

transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount",
"4");

I suspect the default will be fine for me anyway, but...the above looks
implementation-dependent. Am I essentially guaranteed to be using the
Apache Xerces XML component, and thus the implementation-dependent
property is fine? Or is the apparent implementation-dependent property
actually supported by other XML implementations, so there is no cause for
concern?

Or am I back to my previous question, with respect to whether the method
I'm using to get the DOMImplementation is actually portable for all Java 5
implementations?

The DocumentBuilder-based solution works on both OS X 10.4's Java and Java
6 on Windows XP. But that's a pretty limited test. I'm wondering if it's
truly universal or if there are Java implementations for which that won't
work.

Thanks,
Pete

 

[Arne Vajhøj]

I'm looking for something that would already be in the JRE.

Is it that bad to have your jar file and instruction that it
runs on 1.6 as is and on earlier versions with another jar file
in the classpath. No code changes.

Okay, I see org.xml.sax, with some reader-like things. I assume that's
what you're talking about with SAX. I also see org.w3c.dom.
Yep.


Just looking at the API, it would _seem_ like the DOM packages would be
useful to me. Manipulating an XML document looks very easy.
Constructing a Source and Result for use with a Transformer is also very
easy. And as near as I can tell, I can go both ways.

Unfortunately, I'm having trouble getting a DOMImplementation. The most
reliable technique (at least in my environment) appears to be to get a
DocumentBuilder instance and use that to retrieve the
DOMImplementation.

The standard sequence is:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new File(filename));

But when I look at the class it returns, the package
(com.sun.org.apache.xerces) isn't one I recognize from the Sun Java
docs, which makes me wonder if I can really count on it being installed
in any Java 5 run-time implementation.

This is true interface programming.

You get a Document back and you can call all methods in that
interface.

All Java implementations (version 1.4 and higher) will have that.

With SUN Java you get a com.sun. class as implementation.

With IBM Java you may get a com.ibm class as implementation.

If you are unhappy with the one that comes with your Java, then
you can another one like Apache Xerces and by defining a system
property get your code to use that.

No code changes.

[SUN are using Xerces in their Java just renaming the package, but
you could still want a newer Xerces for whatever reason]

Xerces is the name of the package I didn't recognize above. If I can
count on it being standard in Java 5, then either the DOM approach or
using the XMLSerializer you mention could be a useful approach. But if
not, it's not suitable for my needs. Is it standard in Java 5?

The code I prefer is:

OutputFormat fmt = new OutputFormat();
fmt.setIndenting(true);
XMLSerializer ser = new XMLSerializer(ps, fmt);
ser.serialize(doc);

You can use either Xerces (package org.apache.xml.serialize) or
the builtin in SUN Java (package
com.sun.org.apache.xml.internal.serialize) - see
above for explanation.

As the name indicate then it is not standard, so you will need
to either distribute with Xerces or assume SUN Java.

Well, writing the code isn't the hard part. Knowing where to look for
the general API I need to use is. Also knowing what's standard in Java
5 and what's not is difficult. My assumption is that if it's not at
http://java.sun.com/javase/6/docs/api/ then it's not part of the
standard Java (and of course, if it's listed there but is "Since 1.6",
it's too recent for my needs). So I appreciate the offer of code, but
what I really need is a map to navigate the various APIs to know which
ones are actually potential solutions or not, based on their portability.

What is supported in what context is very well defined, but
unfortunately not very easy to describe.

Arne

 

[Arne Vajhøj]

I suspect the default will be fine for me anyway, but...the above looks
implementation-dependent.

It is. Bur Xerces is by far the most widely used JAXP implementation.

Am I essentially guaranteed to be using the
Apache Xerces XML component,

Only if you explicit use Xerces or uses a Java version (like newer SUN)
that has Xerces as its default implementation.

Or am I back to my previous question, with respect to whether the method
I'm using to get the DOMImplementation is actually portable for all Java
5 implementations?

The DocumentBuilder-based solution works on both OS X 10.4's Java and
Java 6 on Windows XP. But that's a pretty limited test. I'm wondering
if it's truly universal or if there are Java implementations for which
that won't work.

java.xml
javax.xml
org.w3c.dom
org.xml.sax

must be in any Java implementation of a Java version where they are
required.

org.apache
com.sun

are implementation specific.

Arne

 

[Peter Duniho]

Is it that bad to have your jar file and instruction that it
runs on 1.6 as is and on earlier versions with another jar file
in the classpath. No code changes.

Well, without wasting time on the particulars, yes. It would be that
bad. It would to a large degree negate the whole point of me coding the
project in Java in the first place.

[...]
The standard sequence is:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new File(filename));

Well, that looks like for reading. I'm also (and in one sense, more)
interested in writing. Unless I can write, reading isn't useful to me.

My earlier effort (which does work) was based on some sample code I found,
and it calls DocumentBuilder.getDOMImplementation(), and then uses that to
create a Document instance. But now that you mention it, I see that
there's also DocumentBuilder.newDocument().

Can I assume that calling that is equivalent to getting the
DOMImplementation and using the createDocument() method on that? Or
perhaps it's even superior than bothering with the DOMImplementaton? It
certainly seems simpler if I can just use the DocumentBuilder rather than
messing around with the DOMImplementation instance.

I guess the one difference I see is that I can provide parameters when
creating the document using the DOMImplementation, but I don't see how to
replicate those going through the DocumentBuilder. But I suspect that
comes down to my inexperience with XML, and that there's probably some
general-purpose method on the Document itself that I can use to configure
the document properties (for example, the document namespace and name). I
just need to look for it. (But if someone can spoil the adventure for me
by just telling me the method and/or parameters needed, feel free ).

This is true interface programming.

You get a Document back and you can call all methods in that
interface.

All Java implementations (version 1.4 and higher) will have that.

I realize that all Java implementations will support the interface. But
that's different from saying that on all Java implementations I'll be able
to get an instance of the interface, via the mechanism described here
(e.g. using DocumentBuilder). Can you clarify that the latter is true?

With SUN Java you get a com.sun. class as implementation.

With IBM Java you may get a com.ibm class as implementation.

Well, I know for a fact those aren't the only Java implementations.
Fortunately, the Apple implementation is known to me to support this
(since it works ). Are the above the only other Java implementations?
If not (and I suspect not), am I guaranteed to get _some_ implementation
of Document, regardless of the implementation? Or is a provider for this
interface optional?

If you are unhappy with the one that comes with your Java, then
you can another one like Apache Xerces and by defining a system
property get your code to use that.

No code changes.

I'm only "unhappy" if no implementation at all is provided. But
installing an implementation isn't an option. I'm looking for something
as close to "write-once, run everywhere" as possible. After all, that
goal is the main reason I'm even using Java. So it's important to me to
know the difference between something that is found in several
implementations versus something that is guaranteed to be found in any
Java 1.5-compliant implementation.

Thanks for the help.

Pete

 

[Arne Vajhøj]

Well, that looks like for reading. I'm also (and in one sense, more)
interested in writing. Unless I can write, reading isn't useful to me.

My earlier effort (which does work) was based on some sample code I
found, and it calls DocumentBuilder.getDOMImplementation(), and then
uses that to create a Document instance. But now that you mention it, I
see that there's also DocumentBuilder.newDocument().

Can I assume that calling that is equivalent to getting the
DOMImplementation and using the createDocument() method on that? Or
perhaps it's even superior than bothering with the DOMImplementaton? It
certainly seems simpler if I can just use the DocumentBuilder rather
than messing around with the DOMImplementation instance.

It is.

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.newDocument();
Element one1 = doc.createElement("one");
one1.appendChild(doc.createTextNode("A"));
Element one2 = doc.createElement("one");
one2.appendChild(doc.createTextNode("BB"));
Element one3 = doc.createElement("one");
one3.appendChild(doc.createTextNode("CCC"));
Element all = doc.createElement("all");
all.appendChild(one1);
all.appendChild(one2);
all.appendChild(one3);
doc.appendChild(all);

I guess the one difference I see is that I can provide parameters when
creating the document using the DOMImplementation, but I don't see how
to replicate those going through the DocumentBuilder. But I suspect
that comes down to my inexperience with XML, and that there's probably
some general-purpose method on the Document itself that I can use to
configure the document properties (for example, the document namespace
and name). I just need to look for it. (But if someone can spoil the
adventure for me by just telling me the method and/or parameters needed,
feel free ).

doc.createElementNS create elements with namespace.

I realize that all Java implementations will support the interface. But
that's different from saying that on all Java implementations I'll be
able to get an instance of the interface, via the mechanism described
here (e.g. using DocumentBuilder). Can you clarify that the latter is
true?

It is true. DocumentBuilderFactory and DocumentBuilder will be in
any Java implementation version 1.4 or newer.

(and for 1.3 you can get them as external packages)

Well, I know for a fact those aren't the only Java implementations.
Fortunately, the Apple implementation is known to me to support this
(since it works ). Are the above the only other Java
implementations? If not (and I suspect not), am I guaranteed to get
_some_ implementation of Document, regardless of the implementation? Or
is a provider for this interface optional?

You will always get some implementation of Document.

There are many implementation: SUN, IBM, BEA and Oracle each has
their own.

Companies like HP and Apple also have their own for their
operating systems and hardware.

My guess is that the last category base their versions
on the SUN version.

I'm only "unhappy" if no implementation at all is provided. But
installing an implementation isn't an option. I'm looking for something
as close to "write-once, run everywhere" as possible. After all, that
goal is the main reason I'm even using Java. So it's important to me to
know the difference between something that is found in several
implementations versus something that is guaranteed to be found in any
Java 1.5-compliant implementation.

Then W3C DOM and outputting via XSLT seems as the way to go.

Arne

 

[Peter Duniho]

[...]
You will always get some implementation of Document.

Okay, good news. Thanks for all the pointers. Looks like I've got a
plan.

 

[Peter Duniho]

It is. Bur Xerces is by far the most widely used JAXP implementation.

Um. Well, I suppose I can live with that if I have to. But I'm hoping I
don't.

It turns out the default isn't fine for me after all, as the default turns
out to be 0.

I don't understand why the default should be 0. That's basically "no
indent", which is pretty much the last thing someone would want, I think,
if they've specifically set a property named "indent" to "yes".

But, given that the default apparently is 0, doesn't it make sense that
the base API would offer some way to change it to a value that actually
_indents_?

Why would they provide the "indent" property, but not offer any way to
actually get the XML indented?

I see two possibilities that would be preferable to just using the Xerces
qualification for the property:

* Somehow getting the actual URI for the qualification from the
Document or DocumentBuilder, and using that. There still remains the
chance that a non-Xerces implementation wouldn't understand the
"indent-amount" property, but at least those that follow that convention
would indent properly. The XML is still usable without indentation, so
this is more about getting the indentation to work in as many
implementations as possible, rather than the application breaking when it
doesn't.

* Even better, and ideal IMHO, would be a property name that is
guaranteed to work unqualified on all Java 5 implementations and later.

Are either of these possibilities available to me?

Pete

 

[Peter Duniho]

[...]
I see two possibilities that would be preferable to just using the
Xerces qualification for the property:

[...]
* Even better, and ideal IMHO, would be a property name that is
guaranteed to work unqualified on all Java 5 implementations and later..

Are either of these possibilities available to me?

Ding-ding! We have a winner. Maybe.

Okay, I found a bug report
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6296446) complaining
that setting an "indent-amount" property for a specific qualified URI
doesn't work. Contained in that was a description of a work-around that,
lo and behold, the work-around for that bug solves my issue as well.

In particular, calling TransformerFactory.setAttribute() with the name
"indent-number" and the indent value I want actually causes the desired
indentation to happen (provided I also set the "indent" property on the
subsequently created Transformer instance to "yes", of course).

The thing is, I don't see any explicit documentation of this attribute.
The documentation for set/getAttribute seem to imply that the attribute is
implementation-specific. So even though it's not qualified, I'm concerned
that I'm still relying on implementation-dependent behavior.

Does anyone have any specific knowledge of this technique who is willing
to comment on the validity or usefulness of it? My current proposed use
is to use that work-around, putting the call to setAttribute() in a
try/catch block and just ignoring any error. The worst that would happen
in that case is my XML doesn't get indented.

(It's funny...I've been doing some Googling, obviously, on this issue and
it appears that not only is how to get XML indented as desired using Java
a broadly-confronted issue, there's a surprisingly large number of ways to
accomplish it. Here's a sample thread:
http://forum.java.sun.com/thread.jspa?threadID=562510 (I'm especially
enamored of the technique in reply #22, in spite of -- or maybe because of
-- the fact that it's relatively complicated, as compared to just
setting an attribute on the TransformerFactory)).

Thanks,
Pete

 

[Roedy Green]

Is there any simple XML support in Java 5? If so, can you please point me
to the appropriate class name or documentation page?

Why are you limited to Java 5?
Java 6 came out over a year ago on 2006-12-12

 

[Simon Higgs]

Why are you limited to Java 5?
Java 6 came out over a year ago on 2006-12-12

From the OP -
User-Agent: Opera Mail/9.24 (MacIntel)

Simon.

 

[Peter Duniho]

Why are you limited to Java 5?
Java 6 came out over a year ago on 2006-12-12

That's an excellent question.

The answer is: because Apple can't be bothered to provide a Java 6
implementation for their operating system. Even for OS X 10.5 (Leopard),
at best they've got a beta download of Java 6, and there's no indication
at all that Java 6 will ever be supported on OS X 10.4 (Tiger) or earlier.

You are right...a full year after the release of Java 6, you'd _think_
that you could rely on it being ubiquitous. But if you did, you'd be
wrong.

If I seem a bit bitter about this, well...it's because I am.

Pete

 

[Arne Vajhøj]

Um. Well, I suppose I can live with that if I have to. But I'm hoping
I don't.

It is worth noting that distributing with Xerces would not break WORA.

Xeres is pure Java.

If it is an applet, then the size of the Xerces jar could be a problem,
but for desktop and server apps it is not a problem.

And it is not just me thinking so.

I just checked my harddrive. I have 68 copies of Xerces. Because
so many apps come with it.

BEA, Borland, SUN, JBoss, IBM, Apache, Oracle.

Arne