GCJ
GCJ is an effort by the GCC team to provide an open source Java compiler and
runtime environment to interpret Java bytecode. Unfortunately, the GCJ runtime
environment is not an environment that is often tested on by Eclipse
developers.
The most common problems surrounding GCJ are:
-Eclipse does not start at all
-Eclipse throws a 'java.lang.ClassNotFoundException:
org.eclipse.core.runtime.Plugin' that can be found in the logs (located in
workspace/.metadata/.log)
The workspace's log file is a good place to check to identify whether GCJ is
being used or not. Every Eclipse log session should be prepended with
information about the runtime environment that was used to run Eclipse. The log
may include something like the following:
java.fullversion=GNU libgcj 4.2.1 (Debian 4.2.1-5)
If Eclipse does start, one can check which runtime environment is being used to
run Eclipse by going to 'Help > About Eclipse SDK > Configuration Details'. The
About Dialog itself can also provide other information, the build identifier
can be of particular interest as it is tagged by some distros. This allows the
user to identify whether Eclipse was downloaded through the distribution's
package management system or directly from the eclipse.org website.
Eg:
Build id: M20070212-1330 (Ubuntu version: 3.2.2-0ubuntu3)
The two most common workarounds would be to:
- download the Eclipse binary from eclipse.org directly
- run Eclipse using an alternate Java runtime environment
To download Eclipse, try one of the links below:
It is imperative that 64-bit builds are downloaded and used if a 64-bit Java
runtime environment has been installed. Below are two sample tarball names of
version 3.3.2 of the Eclipse SDK packaged for 32-bit and 64-bit processors.
eclipse-SDK-3.3.2-linux-gtk.tar.gz (32-bit)
eclipse-SDK-3.3.2-linux-gtk-x86_64.tar.gz (64-bit)
To run Eclipse with an alternate Java runtime environment, the path to the Java
virtual machine's binary must be identified. With an Eclipse installation from
the distribution, altering the $PATH variable to include the path to the
alternate Java runtime environment is often not enough as the Eclipse that
Linux distributions package often performs a scan internally to pick up GCJ by
itself whilst ignoring what's on the $PATH. An example of the terminal's output
can be seen below:
searching for compatible vm...
testing /usr/lib/jvm/java-7-icedtea...not found
testing /usr/lib/jvm/java-gcj...found
Once the path to the virtual machine's binary has been identified, try running
Eclipse with the following command:
./eclipse -vm /path/to/jre/bin/java
For an actual example, it might look something like the following:
./eclipse -vm /usr/lib/jvm/sun-java-6/bin/java
./eclipse -vm /opt/sun-jdk-1.6.0.02/bin/java
If this seems to solve the problem, it is likely that the problem really was
related to the use of GCJ as the Java runtime for running Eclipse. The
eclipse.ini file located within Eclipse's folder can be altered to
automatically pass this argument to Eclipse at startup. An example of its
content is presented below:
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vm
/opt/sun-jdk-1.6.0.02/bin/java
-vmargs
-Xms40m
-Xmx512m
Note that every argument must be on its own line. More information about the
eclipse.ini file can be found at
https://wiki.eclipse.org/Eclipse.ini.
If problems persists after downloading an installation of Eclipse from
eclipse.org and using a supported Java runtime environment (a list of which may be found in the readme_eclipse.html supplied with your installation), one should seek
assistance from the Eclipse team via its plethora of communication channels
like the
newsgroups, the IRC
channel, and/or
bugzilla.