no comments. Full degradation of developers.

Here's a fixed check-java.sh file

#!/bin/sh#
# check for correct java version by parsing out put of java -version
# we expect first line to be in format 'java version "1.8.0_161"' or 'java version "10.0.1" 2018-04-17'
# or 'openjdk version "11-ea" 2018-09-25' and assert that version number will be 8 or 11 (if enabled)
# or sth like 'Picked up JDK_JAVA_OPTIONS:' (which we need to skip)
#java_raw_version=`echo "$($_RUNJAVA -version 2>&1)" | grep -v "JDK_JAVA_OPTIONS" | grep "version" | awk '{ print substr($3, 2, length($3)-2); }'`
java_version=0if [[ $java_raw_version = *-ea* ]]
then
    # early access format e.g 11-ea
    IFS='-' read -a values <<< "$java_raw_version"
    java_version=${values[0]}
else
    if [[ $java_raw_version = 1.* ]]
    then
        # old format e.g. 1.8.0_161
        IFS='.' read -a values <<< "$java_raw_version"
        java_version=${values[1]}
    else
        # new format e.g. 10.0.1
        IFS='.' read -a values <<< "$java_raw_version"
        java_version=${values[0]}
    fi
fiif [ $java_version -ne 8 ] && [ $java_version -ne 11 ]
then
    echo "****************************************************************************"
    echo "*******      Wrong JVM version! Jira requires 1.8 or 11 to run.      *******"
    echo "****************************************************************************"
    echo "***"
    echo "*** Output of java -version command is:"
    $_RUNJAVA -version 2>&1
    echo "*** (End of output) ***"
    echo "***"
    if [ "$ignore_jvm_version" = "true" ]
    then
        echo "*** Environment variable 'ignore_jvm_version' is set to 'true'"
        echo "*** Jira is going to bypass restriction and run using existing JVM version"
        echo "***"
        echo "****************************************************************************"
    else
        echo "*** If you want Jira to start using this JVM"
        echo "*** set environment variable 'ignore_jvm_version' to 'true'"
        echo "***"
        echo "****************************************************************************"
        exit 1
    fi
fi   

For those who don't know shell scripting well enough, here's a fixed check-java.sh file that takes into account both major and minor versions...

#!/bin/sh

_EXPECTED_JAVA_MAJOR_VERSION="1"
_EXPECTED_JAVA_MINOR_VERSION="8"

#
# check for correct java version by parsing out put of java -version
# we expect first line to be in format '(java|openjdk) version "1.8.0_40"' and assert that minor version number will be 8 or higher
#

"$_RUNJAVA" -version 2>&1 | perl -nE 'if ( /(?:java|openjdk)\s+version\s+"?([\d\.]+)"?/ ) { print "$1\n" }' | (
        OK=0
        IFS=. read major minor build
        if [ ${major:-0} -gt "$_EXPECTED_JAVA_MAJOR_VERSION" ]; then
          OK=1
        elif [ ${major:-0} -eq "$_EXPECTED_JAVA_MAJOR_VERSION" ] && [ ${minor:-0} -gt "$_EXPECTED_JAVA_MINOR_VERSION" ]; then
          OK=1
        fi
        if [ $OK != 1 ]
        then
          echo "******************************************************************************"
          echo "***  Wrong JVM version! You are running with $major.$minor.$build"
          echo "***  but JIRA requires at least 1.8 to run."
          echo "******************************************************************************"
          exit 1
        fi
    )
if [ $? -ne 0 ] ; then
   exit 1
fi

 

That doesn't fix the problem!
Holy crap, don't hack scripts if you don't know what you are doing.

If you want to run this script stand-alone you need to set the variable _RUNJAVA first.
export _RUNJAVA=java

./check-java.sh; echo $?

It should print 0 indicating the script returned with no error.
This won't tell you much though since you're probably not running in the same context that Jira is launched in. (su -l jira first maybe?)

This script looks like it's run from some other part of the Jira start-up process and if it fails it will probably log it.

On check-java.sh file I changed the expected version to 0 and worked!

#!/bin/sh

_EXPECTED_JAVA_VERSION="0"

#

1. check for correct java version by parsing out put of java -version
2. we expect first line to be in format 'java version "1.8.0_40"' and assert that minor version number will be 8 or higher
   #

"$_RUNJAVA" -version 2>&1 | grep "java version" | (
IFS=. read ignore1 version ignore2
if [ ! ${version:-0} -ge "$_EXPECTED_JAVA_VERSION" ]
then
echo "*************************************************************************************************************************************"
echo "********** Wrong JVM version! You are running with "$ignore1"."$version"."$ignore2" but JIRA requires at least 1.8 to run. **********"
echo "*************************************************************************************************************************************"
exit 1
fi
)
if [ $? -ne 0 ] ; then
exit 1
fi

Hey guys,
I'm having the same issue here:
"Wrong JVM version! You are running with java version "9.0.1" but JIRA requires at least 1.8 to run."

Any suggestions??

Jira 7.7.0
JDK 9.0.1
HighSierra 10.13.2 

Thanks in advance!
Pablo

found it!! in check-java.sh ... got it working now

hey Alfredo, do you have the complete solution? I have the same problem and really want to get this Jira software running!
best regards,
and happy holidays,
Peter

Same problem here

• ubuntu x86
• Jira 7.6.0
• openjdk version "1.8.0_151"
• OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
• OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

Hey guys,

I think I'm getting a similar issue with Java version 9.

"Wrong JVM version! You are running with java version "9.0.1" but JIRA requires at least 1.8 to run." 

I'm trying JIRA 7.6.0 in MacOS:

16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64

Wasn't this version supposed to work?

Thanks,

Frederico

@herve 

Yes, Atlassian support provided the  following 

/usr/bin/java -version 2>&1 | grep 'openjdk' | (

This worked on Centos7 for JIRA 7.0.11. However, I am planning to upgrade past this version due to all of the gotchas. 

Hello,

I have the same issue on a Debian 9.

Did you find a solution?

Thank you,

Hervé

@William Byrne. I am testing the script due to it being called within ./start-jira.sh  && ./catalina.sh.

[root@----- bin]# _RUNJAVA=java ./check-java.sh
*************************************************************************************************************************************

• • • • • • • • • • Wrong JVM version! You are running with .. but JIRA requires at least 1.8 to run. **********
                    *************************************************************************************************************************************

@Scott  Kimber here is mine.. Seems the same version from the EPEL Repo 
[root@---- bin]# java -version
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (build 1.8.0_144-b01)
OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
[root@---- bin]#

Calling ./catalina.sh manually shows Using JRE_HOME: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.144-0.b01.el7_4.x86_64/jre/bin/. which I changed from /usr/lib/jvm/jre-1.8.0/bin/ which didnt work as well. Was this check enabled only in the 7.0.0?

@Al Nash

If you're testing the script, try something like:

_RUNJAVA=java ./check-java.sh

That file appears to be set correctly.  What is your output when you run this?

$ java -version

Here is mine:

$ java -version
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (build 1.8.0_144-b01)
OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)

@ScottKimber 

I am having difficulty getting the ./check-java.sh modifcation to work on CentOS7 with OpenJDK. (See Below)

// code placeholder

#!/bin/sh

_EXPECTED_JAVA_VERSION="8"

#
# check for correct java version by parsing out put of java -version
# we expect first line to be in format 'java version "1.8.0_40"' and assert that minor version number will be 8 or higher
#

"$_RUNJAVA" -version 2>&1 | grep -E "(openjdk|java) version" | (
IFS=. read ignore1 version ignore2
if [ ! ${version:-0} -ge "$_EXPECTED_JAVA_VERSION" ]
then
echo "*************************************************************************************************************************************"
echo "********** Wrong JVM version! You are running with "$ignore1"."$version"."$ignore2" but JIRA requires at least 1.8 to run. **********"
echo "*************************************************************************************************************************************"
exit 1
fi
)
if [ $? -ne 0 ] ; then
exit 1
fi

I receive the same error.  How were you able to proceed?

why not support openjdk？？？

The modification to java_check.sh worked perfectly for me on CentOS 7 with openJDK.  Thank you very much.

I am having the same problem as Randy...   Appears that _RUNJAVA is not defined at the time 'check-java.sh' is called from 'catalina.sh'...   _RUNJAVA is defined in 'config.sh' just before calling 'check-java.sh'...

Anyone have a solution for this issue...

On Ubuntu 15.10, I still had issue with check-java.sh, even after installing oracle's java:
root@dev:/opt/atlassian/jira/bin# javac -version
javac 1.8.0_66
root@dev:/opt/atlassian/jira/bin# java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
root@dev:/opt/atlassian/jira/bin# ./check-java.sh
Wrong JVM version! You are running with .. but JIRA requires at least 1.8 to run.

But when I use versions.sh it shows the correct versions:
Server startup logs are located in /opt/atlassian/jira/logs/catalina.out
Using CATALINA_BASE: /opt/atlassian/jira
Using CATALINA_HOME: /opt/atlassian/jira
Using CATALINA_TMPDIR: /opt/atlassian/jira/temp
Using JRE_HOME: /opt/atlassian/jira/jre/
Using CLASSPATH: /opt/atlassian/jira/bin/bootstrap.jar:/opt/atlassian/jira/bin/tomcat-juli.jar
Using CATALINA_PID: /opt/atlassian/jira/work/catalina.pid
Server version: Apache Tomcat/8.0.17
Server built: Jan 9 2015 15:58:59 UTC
Server number: 8.0.17.0
OS Name: Linux
OS Version: 4.2.0-22-generic
Architecture: amd64
JVM Version: 1.8.0_51-b16
JVM Vendor: Oracle Corporation

It appears that the _RUNJAVA variable is not set (null value) if you run check-java.sh by itself. This was determined by adding a debug line in check-java.sh
echo "(DEBUG) RUNJAVA: '$_RUNJAVA'"

It seems to run fine if you add the following line, within check-java.sh :
_RUNJAVA="java"
However, I am not sure if this will break other components within the Jira app.

Hope this helps,

-Randy

Hi anh1,

The script doesn't support OpendJDK, because OpenJDK is not a supported platform for JIRA.

Atlassian only supports running JIRA with the Oracle JDK. For more information please refer to our [https://confluence.atlassian.com/display/JIRA/Supported+Platforms|Supported Platforms documentation]

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

Ah, I forgot to post our solution:
I found the script which does the check and fixed it to also work with openJDK, because that's exactly the problem: The script only works with Oracle Java, but not with any openJDK implementation.
It seems, that if you would have Oracle Java installed, the 'java -version' command outputs something like

java version "1.8.0_66"

but if you use an openJDK implementation, the command outputs

openjdk version "1.8.0_66"

So the fix in script 'bin/check-java.sh' looks like this:
Replace

"$_RUNJAVA" -version 2>&1 | grep "java version" | (

with

"$_RUNJAVA" -version 2>&1 | grep -E "(openjdk|java) version" | (

This enables the usage of extended regular expressions in the pattern of the grep command so the brackets and the OR works. Then it also checks for "openjdk", additionally to "java". Tada: fixed

JAVA_HOME should definitely be set in order for this to work, or even better JRE_HOME (if you are running Bamboo on the same machine). This script checks if this variable is set, and if not, tries to guess where the JRE might be located (the JRE which comes bundles with Jira).

This "guessing" step is what I dislike mostly, and it would be much better if the script would simply fail immediately and report a meaningful error.