(Previously posted as news://news.eclipse.org:firstname.lastname@example.org)
I’ve been going through a rough time to get my system working again after I messed up my Linux. I have openSuse 10.3 on a 64-bit system. Eclipse was the toughest part to get right. I’ll explain my sores here, just in case anybody else has the same problem, he shouldn’t go through all this.
Installing Eclipse via the package manager, YaST2, does not work. If you go to Help → Software updates… → Manage configuration afterwards, you’ll see that all plugins have missing dependencies or whatever. Furthermore, it tends to crash.
Using a downloaded Eclipse with the java 1.6 from YaST2 doesn’t work. Java 6 Update 4 crashes Eclipse all the time. Going back to update 3 makes things a little more stable, but still things go wrong.
Even with a self-installed 64-bit Java from Sun, it still wasn’t stable enough to do decent work.
My final solution was to download the 32-bit version of Java 6 update 4, install it in /usr/local/ , a 32-bit version of Eclipse, put it in /usr/local/ , and starting Eclipse with -vm pointing to that Java. It also helps to make /usr/local/eclipse writable for the world, that way you can install plugins there as a user. It is unclear to me where the problem lies. I got OMEs warning about PermGen space, but playing around with -XX:MaxPermSize=256m and --launcher.<the corresponding option> but this didn’t seem to be the culprit, since now with the 32-bit versions, it works (I do have -XX:MaxPermSize=128m and -Xmx1g in there now). So either there is something wrong with Sun’s Java (probably, and definitely with update 4), or with Eclipse (although maybe less probably, I think there is as well), or the two just don’t fit together.
Update: today, 64-bit Eclipse is running fine (I’m writing this in the XML editor), both with hand-installed Sun 64-bit Java, and with Suse’s Java. Beats me.
Update (3 April 2008): The upgrade to Java 1.6u5 did it again: once again, 32-bit Eclipse with hand-installed 32-bit Java is the only one working.
However, this has made me think of something: could it be workspace-related? The 64-bit Eclipse is working on an old workspace which I do not use for development, only for this web-editing.
Update (16 May 2008):Someone on the Subclipse mailing list (accessed here as newsgroup) suggested this might have to do with pre-64-bit stuff in the eclipse configuration directory, and one would have to clean it out. I haven’t tried this (since stuff works fine now), but it’s worth a try if it gets stuck again…
If you have switched to 64bit but are using the same workspace that you used on the 32bit system, try to delete the folders under <eclipse>/configuration (keep config.ini file) and create a fresh workspace and import the projects from the old workspace (in short start with a fresh eclipse install). This usually solves a lot of problems that starting eclipse with -clean doesn't fix, and seems good practice when switching JVM or system architecture.
But then, the system has never been 32-bit.
Update (27 June 2008): Here we are again. Upgrade to openSUSE 11.0. Pre-packaged version not working, with any Java 6 (openJDK, Sun). Self-installed 64-bit Eclipse Ganymede not working either, with any java (that is, the packaged one, or even a self-installed 64 bit Sun jdk). Not working in both cases meaning: it starts and runs, but breaks down after a while, either with Bug Buddy popping up, or no warning at all.
Finally, once again, a 32-bit Ganymede with a self-installed 32-bit Java is saving my day.
But then, I have been writing this in the 64 bit version with the pre-installed java, and it hasn’t crashed in a few minutes…
Finally, the error seems to be known. Anton Leherbauer pointed it out
to me in a
post on eclipse.newcomer: it is a jvm bug (that’s what one could
expect, with all the jvm error logs): bug
6614100 in Sun’s bug database. The bug is marked
but this isn’t yet in the latest Java 6 update, it will probably be in
the next. The corresponding Eclipse
bug report gives a workaround: add
to your eclipse.ini file, after
-vmargs, well understood.
Final update (28 June 2009): The problem is fixed in the latest Java release indeed.