From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 Description of problem: The batch Eclipse compiler has the classpath ordering wrong. It's placing bootclasspath before classpath. This makes it impossible to build certain packages using xml-commons-apis, which overrides the org.w3c.dom we have in libgcj. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Try to override a class in your bootclasspath. 2. 3. Additional info:
This is an upstream bug. Can you file it there? You'll need to create an account in eclipse.org's bugzilla, but once you've done that, file it here: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JDT&version=3.1&component=Core
I've filed this bug upstream, including a patch for 3.1.1. https://bugs.eclipse.org/bugs/show_bug.cgi?id=113458 It would be good to get this patch, or something like it, in FC5. I've hit at least a couple of packages that won't build without it.
I have patches in axis and xalan-j2 which are probably workarounds for this.
(In reply to comment #3) > I have patches in axis and xalan-j2 which are probably workarounds for this. Thanks. Isn't any package that puts xml-commons-apis on the classpath basically wrong, since that won't override what's in libgcj (being on the bootclasspath)? xml-commons-apis should go in a endorsed dir, no? Does ecj put endorsed dir jars in the right place on the classpath?
(In reply to comment #2) > I've filed this bug upstream, including a patch for 3.1.1. > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=113458 I've closed this bug upstream. It seems that the problem is with jpackage's packaging, not ecj.
xml-commons-apis cannot be placed in the endorsed directory because doing so makes it impossible to use the XML parser implementation in libgcj.
See also bug 152255.
So what are we going to do?
(In reply to comment #8) > So what are we going to do? Revert libgcj back to DOM2 from DOM3? The 1.4 JDK used DOM2. 1.5 uses DOM3. The DOM3 we're using in libgcj is the source of these problems.
One idea is to modify our ecj to pull in either DOM2 or DOM3 based on its -source argument.
Any news here?
This is not a bug. ejc's bootclasspath and classpath ordering match Sun javac's 1.5 ordering.