Bug 43022

Comment 1 Grant Gayed 2003-09-12 11:47:22 EDT

Created attachment 6090 [details]
trace

Comment 2 Rafael Chaves 2003-09-12 14:03:26 EDT

Waht JDK/JRE are you using?

Have you by any chance a different Xerces in your classpath? Please look in the
lib/ext directory inside your JRE.

The error you had has to do with a method that was expected in a
org.apache.xerces class (DOMBuilderImpl) not existing.

Comment 3 Grant Gayed 2003-09-12 14:38:49 EDT

- java.fullversion=J2RE 1.4.1 IBM Windows 32 build cn141-20030522 (JIT enabled: 
jitc)
- there isn't a Xerces in jre's lib/ext

Comment 4 Rafael Chaves 2003-09-12 15:16:27 EDT

Reproduced with the same VM but not with Sun JDK 1.4.1_02. Investigating...

Comment 5 John Arthorne 2003-09-12 15:47:11 EDT

Rafael, you can mark as duplicate of 39187 when you're finished investigating.

Comment 6 Rafael Chaves 2003-09-12 16:01:52 EDT

Thanks for pointing it out, John.

With IBM JDK 1.4.1, Xerces comes in the jre\lib directory (xml.jar) and it is in
the boot classpath for any Java application. But Eclipse must use its own Xerces
version. 

You can work around that by:
- renaming the xml.jar to something different (e.g. xml.jar.donotload) - this
has the caveat that any of your other Java programs that need the XML APIs and
share the same JDK will not work.
- prepending the boot classpath with Eclipse's Xerces JARs (xmlParserApis.jar
and xercesImpl.jar) using the -Xbootclasspath/p command-line option. For example: 

eclipse.exe (all your regular options) 
-vmargs
-Xbootclasspath/p:d:\i20030910\eclipse\plugins\org.apache.xerces_4.0.13\xmlParserApis.jar;d:\i20030910\eclipse\plugins\org.apache.xerces_4.0.13\xercesImpl.jar


*** This bug has been marked as a duplicate of 39187 ***

*** This bug has been marked as a duplicate of 39187 ***

Comment 7 Jim Wright 2003-09-17 15:05:30 EDT

I also encountered this problem, using Linux (RH9) and the IBM-Java2-141 SDK.

There is a problem with the workaround posted, at least on Linux:
the name of xmlParserAPIs.jar is spelled with the wrong case ('...Apis' 
vs. '...APIs')in the example. This doesn't matter on Windows, but definitely 
matters on Linux.

With jar name and jar paths corrected for my local installation, Eclipse 3.0M3 
with IBM Java2-141 passed my test case:
1) create a totally empty workspace
2) launch Eclipse with -data pointing at the empty workspace
3) import org.eclipse.core.* and their required projects (all as binary plugin 
projects)
4) Build.

Previously, classpaths were not generated and the build failed.
Now, everything works as expected.

BTW: I first tried renaming .../jre/lib/xml.jar (and xerces.properties) as a 
quick test, but found this didn't work (at least with my RH9 installation as 
configured).  It was necessary to explicitly specify the proper classpaths 
using the -Xbootclasspath/p: option.

Note that the IBM JRE documentation suggests that the boot classpath may
also be augmented using '-Dibm.jvm.bootclasspath=XXX' when launching a Java
application.  The value of this property is prepended to the bootstrap 
classpath, so it should work similarly to -Xbootclasspath/p:.
(However, any value specified using -Xboothclasspath/p: will precede the search 
path(s) specified by ibm.jvm.bootclasspath, so be careful if using both).