On Fri, 11 Feb 2011, Martin Hewitt wrote: > To: CentOS mailing list <centos at centos.org> > From: Martin Hewitt <martin.hewitt at gmail.com> > Subject: Re: [CentOS] CentOS 5.5 Java Process Death > > Hi Keith, > > Interesting idea, I've built the Sun SDK on one server, > and left the yum-installed version on the other, and have > started the same java application on both servers with > strace, so I'll see if there's any difference. > > Thanks for all the help, Well, it's not an idea Martin, it's what I've learnt by experience ;) . For example, the newer versions of Eclipse IDE will not work with GCJ. Please see this excerpt from the installation directory docs of Helios - Eclipse 3.6: /eclipse/readme/readme_eclipse.html 3.1.2 General - 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 is 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 > Installation Details > Configuration. The About dialog itself can also provide other information, the build identifier can be of particular interest as it is tagged by some distributions. This allows the user to identify whether Eclipse was downloaded through the distribution's package management system or directly from the eclipse.org web site. Eg: Build id: M20070212-1330 (Ubuntu version: 3.2.2-0ubuntu3) The two most common workarounds are: * 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: * [40]http://www.eclipse.org/downloads/ * [41]http://download.eclipse.org/eclipse/downloads/ 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.6.0 of the Eclipse SDK packaged for 32-bit and 64-bit processors. eclipse-SDK-3.6-linux-gtk.tar.gz (32-bit) eclipse-SDK-3.6-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 is shown 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... I use the following from Sun's download website: jdk-6u18-linux-i586-rpm.bin The latest 32bit version is available from here: http://www.oracle.com/technetwork/java/javase/install-linux-rpm-137089.html I've noticed other JAVA applications do not work correctly either, on other vendor's java offerings. Which is the reason for grabbing the rpm.bin from Sun/Oracle and installing that. HTH Keith Roberts ----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------