Che will not start when JAVA_HOME does not match "java -version" on Windows

[snorthov]

I put my machine to sleep, then came back. I know this can cause trouble but I won't be rebooting my machine every time I run Che.

Here is what happened when I started the che server (NOTE: I am running Java 8 despite the warnings, see the full transcript):

C:\Users\snorthov\eclipse-che-4.0.0-RC1-SNAPSHOT\bin>che run

On Windows, Che projects can only reside in %userprofile% due
to limitations of Docker. On this computer, %userprofile% is
C:\Users\snorthov

Docker machine named default already exists...
Setting environment variables for machine default...
Docker is configured to use vbox docker-machine named default with IP 192.168.99
.100...

######## HOW TO CONNECT YOUR CHE CLIENT

After Che server has booted, you can connect your clients by:

1. Open browser to http://localhost:8080, or:
2. Open native chromium app.

Che requires Java version 1.8 or higher. We found a lower version.

Looks like something went wrong. Possible issues:

1. (Win | Mac) VirtualBox not installed ==> Rerun Docker Toolbox inst
   allation
2. (Win | Mac) Docker Machine not installed ==> Rerun Docker Toolbox inst
   allation
3. (Win | Mac) Docker is not reachable ==> Docker VM failed to start
4. (Win | Mac) Docker ok, but docker ps fails ==> Docker environment variab
   les not set properly
5. (Linux) Docker is not reachable ==> Install: wget -qO- https:
   //get.docker.com/ | sh
6. (Linux) Permissions not properly set ==> Che must run as UID 1000
   with user in docker group
7. Could not find the Che app server ==> Did /tomcat get moved awa
   y from CHE_HOME?
8. Wrong version of Java found ==> Che requires Java 1.8
9. Did you use the right parameter syntax? ==> See usage

We have seen issues with VirtualBox on Windows where your VM gets corrupted when
your computer is
suspended while the VM is still running. This will appear as SSH or ethernet con
nection issues. This is
rare, but if encountered, current known solution is to uninstall VirtualBox and
Docker Toolbox, and then
reinstall.

Che Environment Variables:
(REQUIRED) JAVA_HOME ==> Location of Java runtime
(REQUIRED: WIN|MAC) DOCKER_TOOLBOX_INSTALL_PATH ==> Location of Docker Toolbo
x
(REQUIRED: WIN|MAC) VBOX_MSI_INSTALL_PATH ==> Location of VirtualBox
(OPTIONAL) CHE_HOME ==> Directory where Che is in
stalled
(OPTIONAL) CHE_LOCAL_CONF_DIR ==> Directory with custom Che
.properties files
(OPTIONAL) CHE_LOGS_DIR ==> Directory for Che output
logs
(OPTIONAL) CHE_DOCKER_MACHINE_NAME ==> (Win | Mac) Name of VM cr
eated by docker-machine
(OPTIONAL) DOCKER_MACHINE_HOST ==> (Linux) Docker host IP -
set if browser clients remote

Usage:
che [OPTIONS] [run | start | stop]
-i, --image Launches Che within a Docker container using late
st image
-i:tag, --image:tag Launches Che within a Docker container using spec
ific image tag
-p:port, --port:port Port that Che server will use for HTTP requests;
default=8080
-r:ip, --remote:ip If Che clients are not localhost, set to IP addre
ss of Che server
-g, --registry Launch Docker registry as a container (used for w
s snapshots)
-m:vm, --machine:vm For Win & Mac, sets the docker-machine VM name to
vm; default=default
-s:client, --skip:client Do not print browser client connection informatio
n
-s:uid, --skip:uid Do not enforce UID=1000 for Docker
-h, --help Show this help
-d, --debug Use debug mode (prints command line options + app
server debug)
run Starts Che application server in current console
start Starts Che application server in new console
stop Stops Che application server

The -r flag sets the DOCKER_MACHINE_HOST system environment variable. Set this t
o the IP address of the node
that is running your Docker daemon. Only necessary to set this if on Linux and y
our browser clients are not
localhost, ie they are remote. This property automatically set for Che on Window
s and Mac.

C:\Users\snorthov\eclipse-che-4.0.0-RC1-SNAPSHOT\bin>java -version
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) Client VM (build 25.73-b02, mixed mode)

C:\Users\snorthov\eclipse-che-4.0.0-RC1-SNAPSHOT\bin>echo %JAVA_HOME%
C:\Program Files (x86)\Java\jre1.8.0_66

C:\Users\snorthov\eclipse-che-4.0.0-RC1-SNAPSHOT\bin>

[TylerJewell]

Please install rc 3 released today. There is an option there that allows skipping the Java check I believe. I also encourage you to install the branch associated with #257 where there is a new startup script which solves issues with docker. Also there was a significant bug in boot2docker that was resolved on 1.10 released by docker five days ago. You may need to consider updating to that version.

[ghost]

It is a good practice to at least shut down the VM before you put your laptop to sleep. Virtual Box can behave weirdly after some idle time and hibernation.

So, power off the VM or run docker-machine stop default

Also, java -version and echo %JAVA_HOME% return different versions for you. I do not think this is what has caused the issue but maybe you may want to fix it.

To debug the script, please open /bin/che.sh and look for the following line https://github.com/codenvy/che/blob/master/assembly-main/src/assembly/bin/che.sh#L481

add echo $JAVA_VERSION just below this line. If it returns an empty string, then there's smth a script does not take into account. I have has this issue when I had JAVA_HOME path with " " in env variables.

[snorthov]

The thing is this: Everything was working fine and then it all stopped. I'm guessing that it is because of putting the laptop to sleep, however, a new version of Java and forced Windows 7 Updates might have burned me.

I will first look at the che.sh script in hopes that this will fix the problem verus re-installing. If that fails, I will reinstall RC3.

[snorthov]

I have fixed the JAVA_HOME and command line java versions to match. It now works. I need to put it back to make sure that this is the problem. Before that I deleted the AppData Che directory in an attempt to fix things. It didn't. In any case, this is all that has changed.

I'll close this once I know that the different Java versions caused the problem.

[TylerJewell]

@snorthov The two versions of Java is likely the culprit. Was it the case that after your forced windows update that JAVA_HOME was no longer pointing to a valid directory?

[snorthov]

Not sure but will try to investigate more.

[snorthov]

Confirmed, a mismatching JAVA_HOME causes che to fail to launch. You might try to succeed in this case and pick one? Up to you. In any case, the message is wrong (it says I need "Java 8" but both versions were 8).

[TylerJewell]

I think I have sourced the issue.

JAVA_VERSION=$("${JAVA_HOME}/bin/java" -version 2>&1 | awk -F '"' '/version/ {print $2}')
if [[  -z "${JAVA_VERSION}" || "${JAVA_VERSION}" < "1.8" ]]; then
  error_exit "Che requires Java version 1.8 or higher. We found a ${JAVA_VERSION}."
  return
fi

In this situation, if JAVA_VERSION returns empty, then it will trigger the error message. And in your case, JAVA_HOME was no longer pointing to a valid Java version. It was gone. This code ran, placed a blank JAVA_VERSION, and that triggered the error message.

[snorthov]

Actually, both versions of java were still there. It's easy enough to create the failure case by changing JAVA_HOME. Glad we got to the bottom of it!

[ghost]

I was able to reproduce it by:

1. Installing JDK 1.8.0.71
2. Setting JAVA_HOME to point to ..0.71/bin
3. Removing old java and installing new one - 0.73 this time.

As a result, JAVA_HOME pointed to the old non-existing path, while java -version returned information on the new version. The installator adds Java to path automatically, while JAVA_HOME is managed by user.

I think the right way to go is to check if $(JAVA_HOME}/bin/java exists

[snorthov]

I'm telling you that I made the problem happening as well by not removing Java. I'm guessing that your steps also fail but you will need to be aware of both failure cases. Perhaps your fix will fix both.

[snorthov]

ie. two valid Java 8's on my machine. The one seen by running "java" on the command line begin different from the one pointed to by JAVA_HOME.

[ghost]

The script should not fail then. If %JAVA_HOME%\bin\java exists there should not be any obvious reasons why JAVA_VERSION returns an empty string.

I'll try it with 2 valid Javas

If you feel like helping me debut it, https://github.com/eclipse/che/blob/master/assembly/assembly-main/src/assembly/bin/che.sh#L481 - echo $JAVA_VERSION just after variable declaration. If it's empty, then JAVA_HOME points to a dire with bin/java in it.

[TylerJewell]

@snorthov I'd love to do another live debugging session. On Windows 10, just completed the following test:

1. JAVA_HOME = JDK 1.8.0_45
2. java -version = JRE 1.8.0_51

When I ran Che, there were no errors on the JAVA_HOME check. I think Eugene was able to reproduce an error where if JAVA_HOME is not pointing to a valid directory, then the script fails. But we do print out a nice error message indicating that this is needed for a fix. So I don't think the empty JAVA_HOME is the issue.

[ghost]

Yes, I was able to run Che with the following messed up JAVA env stuff:

I got it by updating Java, though JAVA_HOME pointed to the old Java location. However, since the script uses JAVA_HOME to run java -version command, and since this path existed in my Program Files, it was totally ok for this java version check.

[snorthov]

I had a nightly version of Che that Tyler and I had played with (we inserted echo's and deleted an "exec"). I am running RC3 or something like that now. I will check this again on the latest. As you can see from the original transcript I entered, I had the error "Che requires Java version 1.8 or higher. We found a lower version." and also had two different java's. I am also running on Windows 7.

Like I say, I'll try again on the latest and paste the transcript here if it fails.

[TylerJewell]

Out of curiosity what is the value of your path and Java home variables? Are there spaces or dots in them? Spaces should not matter but if for some reason they do then that could be a possible place to study.

[snorthov]

All the information is in the original report in the first comment of this bug report.

[TylerJewell]

Sorry. That one hs your Java home but not the path to your Java command. Can you share the path?

I do note that the Java home has a space in it.

[snorthov]

Likely the space issue with the error message being misleading. Will report again when I run the latest.

[TylerJewell]

We just did a range of tests where there are spaces and dots in JAVA_HOME, and everything passed. Though these tests were on Win 8 and 10. We will have an engineer repeat this on Win 7 this week.

[TylerJewell]

@snorthov We got feedback from another user on a way to improve the conversion of windows directories from their long form to their short form. I have a pull request for this. As part of this conversion, we are also converting JAVA_HOME into this format as well, which should further cut down on possible issues related to spaces.

#347

[ghost]

I do not believe it to be spaces since if both JAVAs were in the same Program Files directory and fixing JAVA_HOME that points to the valid Java installation solved the issue, that means path with spaces was interpreted correctly.

[ghost]

Tested on 4-5 Win systems with 2 valid Javas. Cannot reproduce with current master and RC3.

Closing the issue. Feel free to reopen if Java update will cause it again.