Bug 166617 - Compiler places bootclasspath before classpath
Compiler places bootclasspath before classpath
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
:
Depends On:
Blocks: FC5Blocker
  Show dependency treegraph
 
Reported: 2005-08-23 17:18 EDT by Anthony Green
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-03 15:51:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anthony Green 2005-08-23 17:18:32 EDT
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:
Comment 1 Andrew Overholt 2005-08-24 08:51:36 EDT
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
Comment 2 Anthony Green 2005-10-22 15:29:59 EDT
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.
Comment 3 Gary Benson 2005-10-24 05:36:40 EDT
I have patches in axis and xalan-j2 which are probably workarounds for this.
Comment 4 Anthony Green 2005-10-24 09:22:28 EDT
(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?
Comment 5 Anthony Green 2005-10-24 09:23:51 EDT
(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.

Comment 6 Gary Benson 2005-10-24 09:38:06 EDT
xml-commons-apis cannot be placed in the endorsed directory because doing so
makes it impossible to use the XML parser implementation in libgcj.
Comment 7 Gary Benson 2005-10-24 09:42:41 EDT
See also bug 152255.
Comment 8 Andrew Overholt 2005-10-27 16:32:05 EDT
So what are we going to do?
Comment 9 Anthony Green 2005-11-06 14:42:02 EST
(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.
Comment 10 Thomas Fitzsimmons 2005-11-09 16:01:03 EST
One idea is to modify our ecj to pull in either DOM2 or DOM3 based on its
-source argument.
Comment 11 Andrew Overholt 2006-02-03 11:16:49 EST
Any news here?
Comment 12 Thomas Fitzsimmons 2006-02-03 15:51:54 EST
This is not a bug.  ejc's bootclasspath and classpath ordering match Sun javac's
1.5 ordering.

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