Re: Patch: FYI: disable XML service files

[Gary Benson <gbenson at redhat dot com>]

Andrew Haley wrote:
> Gary Benson writes:
> > Tom Tromey wrote:
> > > I'm checking this in on the trunk and the RH 4.1 branch.
> > > 
> > > This removes the XML service files from libgcj.so.  This lets us
> > > override things properly again.
> > > 
> > > Andrew, I tried your test case from ifoox, but I can only see the
> > > failure if I back out some of the latest XML bug fixes.  However a
> > > simpler test case shows which thing we're actually loading:
> > > 
> > >     import javax.xml.parsers.*;
> > >     public class q {
> > >       public static void main(String[] args) throws Throwable{
> > >         DocumentBuilderFactory tf = DocumentBuilderFactory.newInstance();
> > >         System.out.println(tf.getClass());
> > >       }
> > >     }
> > > 
> > > Eg, here's the bug in action:
> > > 
> > > opsy. gij -Djava.class.path=/usr/share/java/xerces-j2.jar:. q
> > > class gnu.xml.dom.DomDocumentBuilderFactory
> > 
> > This is actually the correct behaviour: xerces should only be loaded
> > if it is endorsed, and merely being in the classpath should have no
> > effect.  Check this test case with Sun or IBM java:
> > 
> >   import javax.xml.parsers.DocumentBuilderFactory;
> >   public class Test {
> >     public static void main(String[] args) throws Throwable{
> >       DocumentBuilderFactory f = DocumentBuilderFactory.newInstance();
> >       f.setAttribute("bad_attribute", "hello");
> >     }
> >   }
> 
> IMO that's the wrong test.  What matters is this not the
> DocumentBuilderFactory returned, but the DocumentBuilder, and here
> what we do is clearly wrong:
> 
> 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.
We should definitly follow Sun here.

> 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 fiiles except one.  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, and ISTR libgcj has a newer javax.xml with more interface
methods than most versions of xerces expect.

Cheers,
Gary