Bug 42384 - IncompatibleClassChangeError - File does not implement IContainer
Summary: IncompatibleClassChangeError - File does not implement IContainer
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Linux-GTK
: P3 normal (vote)
Target Milestone: 3.0 M4   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-02 10:10 EDT by Douglas Pollock CLA
Modified: 2003-09-03 13:30 EDT (History)
0 users

See Also:


Attachments
Log with initial IBM 1.4.1 build (47.89 KB, text/plain)
2003-09-02 10:11 EDT, Douglas Pollock CLA
no flags Details
Log from second attempt to build (22.66 KB, text/plain)
2003-09-02 10:13 EDT, Douglas Pollock CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Douglas Pollock CLA 2003-09-02 10:10:49 EDT
Doing any kind of build fails with the above error appearing multiple times. 
I'm using IBM JDK 1.4.1 and Eclipse 3.0M3.  The errors still appear after
removing all projects and reconstructing the workspace.  The errors appear with
neither Sun's JDK 1.4.2 nor IBM's SideCar 1.3.1.  The shell command used to
invoke Eclipse is:

/viper/team/dpollock/IBM/Eclipse/eclipse-3.0M3/eclipse/eclipse -vm
"/viper/team/dpollock/IBM/JDKs/IBMJava2-141/jre/bin/java" -data
"/viper/team/dpollock/Projects/eclipse"

Rebuilding with IBM 1.3.1 or with Sun 1.4.2, and then rebuilding with IBM 1.4.1
gives a different set of errors.
Comment 1 Douglas Pollock CLA 2003-09-02 10:11:48 EDT
Created attachment 5932 [details]
Log with initial IBM 1.4.1 build

This is the log from the initial attempt to build using the IBM 1.4.1 JDK.
Comment 2 Douglas Pollock CLA 2003-09-02 10:13:16 EDT
Created attachment 5933 [details]
Log from second attempt to build

This is the log from after a build under IBM 1.4.1 -- after a build had
occurred under IBM SideCar 1.3.1.
Comment 3 Philipe Mulet CLA 2003-09-02 15:37:45 EDT
Can you reproduce it all the time ? On the surface, I would wonder about a 
classloader/vm issue ?! Seems like a binary compatibility issue where it would 
confuse File from java.io and from Eclipse resources.

If a different JRE solves the problem, then this is very likely not our bug.
Comment 4 Douglas Pollock CLA 2003-09-02 15:44:25 EDT
Reproducible every time.  The problem is independent of the JDK used to build 
the source, but is dependent on the JDK running Eclipse.  This is somewhat 
important, as Linux is supposed to move to IBM's JDK 1.4.1 for Milestone 4 
development.
Comment 5 Olivier Thomann CLA 2003-09-02 21:01:15 EDT
Then this looks like a VM issue. Did you try to disable the JIT
(-Djava.compiler=NONE)?
Comment 6 Philipe Mulet CLA 2003-09-03 03:19:46 EDT
I was of course meaning a different JRE to run Eclipse. 
Closing as VM bug, please report to VM vendor.
Comment 7 Douglas Pollock CLA 2003-09-03 09:08:10 EDT
Disabling the JIT with "-Djava.compiler=none" makes things slightly better, but
I still get the XML errors:

java.lang.NoSuchMethodError: org.apache.xerces.parsers.DOMBuilderImpl: method
setFeature(Ljava/lang/String;Z)V not found
Comment 8 Olivier Thomann CLA 2003-09-03 13:30:33 EDT
I would say this is an error resulting from the wrong xml parser on the classpath.