Re: Re: The duplicate class registration problem]

["Anthony Green" <green at redhat dot com>]

Dave wrote:
> I happen to think that libgcj _should_ include XML support, and ideally
> the ClasspathX version (http://www.gnu.org/software/classpathx/jaxp/).
> There are some JDK classes that rely on XML, so libgcj can't avoid the
> problem.

I think it's a mistake to commit to a particular implementation in libgcj.  We
do include a certain level of support for XML in the org.w3c classes.  This
provides an interface for loading implementations providing SAX or DOM APIs.
I am only really familiar with the java.util.prefs stuff, and it appears as
though we can simply use the SAX interface for reading the exported preference
documents.  We can load the parser like so...

org.xml.sax.XMLReader parser
    = (XMLReader)
Class.forName(System.getProperty("gnu.java.util.prefs.XMLImplementation").newI
nstance();

Where gnu.java.util.prefs.XMLImplementation is set to
org.apache.xerces.parsers.SAXParser, or whatever the ClasspathX implementation
is, or something completely different.

This lets us avoid is tremendous code bloat.  Imagine forcing users to load
the ClasspathX implementation while their application uses Xerces.  This is an
important issue for resource constrained devices.  libgcj can simply throw an
appropriate error if the property isn't set or the implementation can't be
loaded.

AG