Re: Patch: FYI: disable XML service files

[Andrew Haley <aph at redhat dot com>]

Gary Benson writes:
 > Andrew Haley wrote:

 > > import javax.xml.parsers.DocumentBuilderFactory;
 > > public class Test1 {
 > >   public static void main(String[] args) throws Throwable{
 > >     DocumentBuilderFactory f = DocumentBuilderFactory.newInstance();
 > >     System.out.println(f.newDocumentBuilder());
 > >     }
 > > }
 > > 
 > >  $ ~/jdk1.5.0_09/bin/java Test1
 > > com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl@18a47e0
 > > 
 > >  $ ~/jdk1.5.0_09/bin/java -classpath /usr/share/java/xerces-j2.jar:. Test1
 > > org.apache.xerces.jaxp.DocumentBuilderImpl@7d8483
 > 
 > Ok, this is where I went wrong.  IBM's JRE does not do this.

Interesting.

 > We should definitly follow Sun here.

Right, we're on the same page.

 > > We don't use Xerces so we can't be compatible with all behaviour
 > > in every possible case, but this is far more like to affect
 > > user-observable behaviour.
 > 
 > We should be okay so long as we have either all service files or no
 > service files.  The bug we had before was because we had all of the
 > service files except one.

Out of interest, which one were we missing?

 > However, making xerces work in the classpath like this will mean a
 > whole load of things that have both xml-commons-apis and xerces in
 > the classpath but not endorsed (eg most everything in Fedora) will
 > now be running xerces with libgcj's javax.xml, 

Which, unless I am very much mistaken, is what has always happened.

 > and ISTR libgcj has a newer javax.xml with more interface methods
 > than most versions of xerces expect.

Sure, but presumably this is also true for everyone else's version 5
libraries, isn't it?

Andrew.