Arch Linux

Xstary

Member

Registered: 2010-08-05

Posts: 20

[SOLVED] Java not starting (stuck) after upgrade

I solved the problem, but I would like to know the reason and would like to post it for reference.

Previously, I had in my .bashrc:

export JAVA_HOME=/usr #OpenJDK

I don’t know why, but with that Java worked.
Recently (not sure with which version, but definitely after switching between JVM with "archlinux-java" was introduced) Java wouldn’t start correclty anymore:
Invoking "java -version" just stucks with 100% CPU usage and no output.

But what did work was

/usr/lib/jvm/java-7-openjdk/jre/bin/java -version
java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.1) (Arch Linux build 7.u65_2.5.1-8-x86_64)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

/usr/lib/jvm/java-default-runtime/jre/bin/java -version
openjdk version "1.8.0_11"
OpenJDK Runtime Environment (build 1.8.0_11-b31)
OpenJDK 64-Bit Server VM (build 25.11-b03, mixed mode)

Removing the "export" line in ".bashrc" solved the problem.

--------------------------------------

Here is my investigation.

So it seemed to have something to do with the wrapper or what it is.
At the update I noticed the replacement of the "/etc/profile.d/jre.sh" file from

export JAVA_HOME=${JAVA_HOME:-/usr/lib/jvm/java-7-openjdk/jre}

# Enable this for non-reparenting window managers
export _JAVA_AWT_WM_NONREPARENTING=1

to

# Do not change this unless you want to completely by-pass Arch Linux' way
# of handling Java versions and vendors. Instead, please use script `archlinux-java`
export JAVA_HOME=/usr/lib/jvm/java-default-runtime

# Enable this for non-reparenting window managers
export _JAVA_AWT_WM_NONREPARENTING=1

This is where the java command was and is pointing to:

ls -alh /usr/bin/java
lrwxrwxrwx 1 root root 28 18. Aug 21:38 /usr/bin/java -> /usr/lib/java-common-wrapper
#$ ls -alh /usr/li
lib/   lib64/ 
#$ ls -alh /usr/lib/java-common-wrapper 
-rwxr-xr-x 1 root root 85  7. Aug 21:21 /usr/lib/java-common-wrapper

Why is there a different "JAVA_HOME" variable needed now? I see that both, the old and the new, "/etc/profile.de/jre.sh" files had an "export" line which seem similar.
What role did the "export" line in the "bash.rc" play? How did removing it solve the issue?

Something must have changed how "JAVA_HOME" is treated, so this probably should be mentioned at the update...

Last edited by Xstary (2014-09-01 13:36:48)

Wikimig

Developer

From: France

Registered: 2004-12-10

Posts: 77

Website

Re: [SOLVED] Java not starting (stuck) after upgrade

> Why is there a different "JAVA_HOME" variable needed now?
JAVA_HOME now points at /usr/lib/jvm/java-default-runtime as specified in jre.sh. This java-default-runtime is set by helper script 'archlinux-java'. The purpose behind this is to enable installation of multiple Java env. For instance you now have a set of OpenJDK 8 packages available in extra. You can install OpenJDK 7 and OpenJDK 8 without conflict and switch between them.

> What role did the "export" line in the "bash.rc" play?
It did not play any role other than set JAVA_HOME to an incorrect value but this **was** not relevant because this value **was** not used.

>How did removing it solve the issue?
JAVA_HOME **is now** used to look for correct JVM install path to use.

These lines were printed when you upgraded to the last OpenJDK 7 packages that explain everything:

Installing multiple non-conflicting Java environments is now supported
Check the following wiki section for more info:
  https://wiki.archlinux.org/index.php/Java#Multiple_official_Java_environments
Please make sure JAVA_HOME is set to /usr/lib/jvm/java-default-runtime
If not, you may have to logout and login again to set it according to /etc/profile.d/jre.sh

(I realize I need to update that link as it points at a wrong section but the page is still valid)

Xstary

Member

Registered: 2010-08-05

Posts: 20

Re: [SOLVED] Java not starting (stuck) after upgrade

Very nice, thank you.
I probably overlooked the important part in the message because I thought it only concerned the usage of multiple envs.