On Fri, 11 Feb 2011, Martin Hewitt wrote:
> To: CentOS mailing list <centos@xxxxxxxxxx>
> From: Martin Hewitt <martin.hewitt@xxxxxxxxx>
> Subject: Re: 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]
-----------------------------------------------------------------
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
