I looked at this a little.
I suspect we want to back out xerces-j-build.patch and
instead use the "IBM JDK 1.4" task to handle setting the
compiler's bootclasspath properly.
This note seems vaguely relevant:
https://www.zarb.org/pipermail/jpackage-discuss/2004-June/005267.html
I think we would also have to include the xerces tool jar in the SRPM.
At least, the current sources don't include the ant task in question.
Also, based on the above, we may need to hack the ant task a little,
depending on whether and how it does the check of java.vendor.

I don't think the java.endorsed.dirs patch will change anything here.
That patch affects the runtime behavior of libgcj. In particular it
lets you override selected parts of the core library.
But as I read this bug, the problem is that the compiler is picking
up newer XML classes than what it expects. That is, it is pulling
these classes out of libgcj.jar directly (compilers don't as a rule
use reflection for this sort of thing).
So, endorsed dirs won't change anything there. That, plus some other
stuff I read, suggests that the fix is to use the "IBM 1.4" build path.

This fix depended on both the xjavac hack and my adding gcj endorsed dirs
support to xml-commons apis. The latter caused no end of problems (see bug
155693) and I've had to revert it, so I'm reopening this while I try and figure
out other, less invasive ways to fix it.

I tested it and it fixes both the simple test case (attachment 115279[details]) and
my original use case that led me to this bug.
I'm not sure what I should change the status to -- I'll leave that to you.
Thanks.

Note

You need to
log in
before you can comment on or make changes to this bug.