Eclipse Classpath Insanity
Eclipse 3.2 is driving me nuts. For reasons I just can’t understand or debug, it keeps throwing NoClassDefFoundError when I try to run most code in my project:
Exception in thread "main" java.lang.NoClassDefFoundError: nu/xom/Element
However, it can compile the classes it complains about not finding just fine. There appears to be a disconnect between the path the compiler sees and what the interpreter sees.
I can run simple Hello World applications in other subpackages (e.g. nu.xom.samples) but not anything in the main package (nu.xom) nor anything in a subpackage that references the main package.
I’ve tried completely reinstalling Eclipse and nuking all my preferences (not an easy task since Eclipse spews them all over various locations on the disk, and tries to hide them from the user) but to no avail. The problem reoccurs.
This is a new development. I used to be able to use Eclipse on this project. I’m not sure what changed to break that. A little googling shows that other people have had problems with similar symptoms, but it’s not clear whether it was the same root cause, or whether any of them were actually able to fix their problems.
At this point I’m about ready to chuck Eclipse completely and once again try NetBeans to see if it’s finally ready for prime time. And if it isn’t, I think there may be an offer a free copy of IDEA sitting somewhere in my Inbox that I haven’t bothered to take advantage of.
Oh my God! I just figured out what’s happening! Believe it or not, the problem is related to this. Eclipse failed to compile one file in nu.xom, UnicodeUtil. That one file is extremely challenging and a real torture test for various tools. It includes some huge lookup tables that cause stack overflows in weak compilers and analyzers. It is legal Java code, and it fits within the bounds of maximum method size, but just barely. Eclipse used to be able to compile it, but it’s been weakening from milestone to milestone. A lot of tools can’t handle this class, and it looks likes between 3.2M4 or thereabouts and 3.2 final Eclipse joined that number. Previously it couldn’t analyze that class, but at least it could compile it. Now it can’t even compile it.
Still that shouldn’t have caused all my problems. It’s just one class that’s not related to a lot of the things I couldn’t run (e.g a HelloWorld program in the nu.xom package with no dependencies on any of the rest of the package.) However, apparently Eclipse compiles in reverse alphabetical order. That is, first it compiles XPathTypeException, then XPathException, then XPathContext, and so on. Eventually it reaches UnicodeWriter, and then UnicodeUtil where it craps out. At this point it stops. It never compiles UnavailableCharacterException, UCSWriter, TextWriterFactory, Node, Element, or any other class that precedes UnicodeUtil in the alphabet. Consequently it can’t find these classes when it comes time to run code that depends on these classes.
There is indeed a disconnect between the path the compiler sees and what the interpreter sees. The compiler and editor appear to be looking at the .java files and analyzing them directly so they don’t report any errors based on the compiler’s failure to generate corresponding .class files. However, the runtime uses the compiled .class files, some of which don’t exist, rather than the .java source files that do exist.
I’m still not sure I can fix this. There’s a real Eclipse bug here causing my pain. In fact there are two: first that it can’t compile a legal file. Second that this failure blocks compilation of other files. If I can’t work around this, I’ll have to switch IDEs anyway, or perhaps just use BBEdit, Ant, and javac (none of which are the least bit fazed by UnicodeUtil). But at least now I know what the problem is so I can stop tearing my hair out, and start moving forward.
P.S. I have a funny feeling that I might have found and fixed this problem sooner and saved myself a lot of grief if I were doing pair programming. Such are the disadvantages of working for yourself. Any agile shops hiring?
August 16th, 2006 at 8:46 am
I’ve filed two bug reports with Eclipse about this:
Eclipse cannot compile classes containing very large methods
August 16th, 2006 at 10:55 am
Gak.
Given that Eclipse should do what the JLS says, do you really have evidence that the unrolled linear searches in getCombiningClass() and decompose() are actually faster or smaller than providing a few honking big strings and doing binary search over them?
You want strings rather than arrays because arrays are initialized at run time with code in <clinit>(), whereas strings are initialized at compile time directly into the constant pool. The difference in class size is huge.
August 17th, 2006 at 12:58 pm
A quick and dirty fix is obvious, isolate the long method into another class, use the “main” class as a delegate.
August 17th, 2006 at 4:03 pm
Keep using Eclipse 3.1 for a while longer. Eclipse 3.2 and the whole Castillo feels somewhat unstable right now. Maybe they took their OSS “predictabillity of delivery” somewhat too seriously
August 18th, 2006 at 1:27 pm
Jan may be right about retreating from 3.2 to 3.1. After rockin’ & rollin’ with many previous versions of Eclipse, my experience with 3.2 has been less than stellar. Too easy to hang up the IDE.
August 20th, 2006 at 2:48 pm
Hi, if you’ll give NetBeans another try we’d like to know from you what was your experience. Even if you decide to stick with another IDE it’s for us interesting to get feedback, we’re preparing future roadmap of NetBeans – so that next time you’ll try NetBeans, you won’t want anything else 🙂
August 24th, 2006 at 8:34 pm
Eclipse 3.2 is definitely NOT ready for production use (unless you are on someone else’s payroll and do not have deadlines)
At startup the “Initializing Java Tool” hangs the IDE, it takes forever to start and publish to Tomcat 5 (look like the IDE is hung), the Project pane incorrectly identifies packages with errors with a red X, and many many more bugs.
I’ve wasted the last 3 weeks with eclipse 3.2 and WTP 1.5 and have opened a bug on bugzilla. Sticking with Websphere Site Studio Developer 5.1.2 (Yes its the old eclipse 2.1) which works reliably for me.
I appreciate the progress on eclipse 3.2 made by the various developers. I will give eclipse 3.2 a shot later in the year as the stable 3.2 release looks like it needs a lot of cleanup.
It appears that eclipse 3.0.1 is still the stable reliable version of eclipse.
October 9th, 2006 at 10:30 am
Would you consider putting dates on your entries? In this case it’s not hard to figure out because the comments are dated, but as they age and come up in searches it’d be nice to know when it was written.
October 9th, 2006 at 8:17 pm
You means something like ” This entry was posted on Wednesday, August 16th, 2006 at 7:56 am and is filed under Java.”, maybe conveniently placed at the bottom of each entry? I don’t know. Seems a little radical. 🙂
December 14th, 2006 at 6:42 am
[…] I seem to be having the same problems as here and will now try Eclipse 3.1 – wish me luck! […]
December 14th, 2006 at 6:54 am
Does anyone know where I can get my hands on Eclipse 3.1? eclipse.org seem to have removed all the older versions for download!
December 28th, 2006 at 7:38 am
Marvelous. Thanks, will spread this among my friends!
May 17th, 2007 at 12:37 pm
My guess is Eclipse throws a StackOverflowError on the kind of pathological
decompose(int)method. It probably uses a recursive descent parser which cannot cope with the deep stacks the gigantic if-else-if would generate. This does not mean compiler/analyzer is weak.Try to compile the class like this: “
javac -J-ss512k UnicodeUtil.java“. It will fail with a StackOverflowError. Javac probably has a stack size of about 1024k by default to cope with this kind of code. Thus increasing the default stack size of Eclipse, any other IDE, compiler or analyzer should help. Rewriting the decompose method to use a switch statement or a prepopulated lookup map would help more.October 7th, 2007 at 10:43 pm
Does anyone know where I can get my hands on Eclipse 3.1? eclipse.org seem to have removed all the older versions for download!