I'm trying to update JVM's Time Zone info using TZUpdater 2.2.0.
> [root#local tzupdater-2.2.0]# java -jar tzupdater.jar -V
tzupdater version 2.2.0-b01
JRE tzdata version: tzdata2018d
tzupdater tool would update with tzdata version: tzdata2018f
So, I'm running the command below:
> [root#local tzupdater-2.2.0]# java -jar tzupdater.jar -l
However, I'm getting this error message:
Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_1/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:000S'
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_1/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377)
at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191)
at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307)
at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153)
at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230)
at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634)
Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000
at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173)
at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210)
at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475)
at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399)
at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354)
... 5 more
I'm using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as the source for the tzdata bundle.
Edited - In addition, I'm using either Java(TM) SE Runtime Environment (build 1.8.0_66-b17) and OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13), meanwhile I have same reported problem using TZUpdater or ZIUpdater
Can anyone help me about this issue? Any comment will be appreciated.
Many thanks.
Yes, the rules for Japan in 1948-1951 changed in 2018f in an "interesting" way: officially, Japan's fall back occurred at 25:00 on Saturday, instead of 01:00 on the Sunday. That confused the Java time zone updater, as well as my own Noda Time project.
There's now a commit to avoid 25:00 in the "rearguard" format - the rearguard format is basically more conservative, avoiding things like Ireland's negative DST.
I would expect a 2018g release at some point reasonably soon, to include that fix. Assuming the tzupdater tool uses the rearguard appropriately, I'd expect that to sort things out. If you can possibly wait until then, I'd do so. Otherwise, use the -l flag on tzupdater to specify a different data source, e.g. for 2018e: https://data.iana.org/time-zones/releases/tzdata2018e.tar.gz
If you need to use version 2018f but not the Asia timezone you can use it from 2018e and the other files from 2018f.
I've created the file tzdata2018f-01.tar.gz in my repository https://github.com/lucasbasquerotto/my-projects/tree/master/tz for anyone that wants to avoid making these manual changes.
There is an example of using ziupdater when creating a docker image with OpenJDK, but if you use Oracle JDK you should be able to use almost the same code to use tzupdater changing
java -jar /app/tmp/ziupdater-1.0.1.2.jar -l file:///app/tmp/tzdata2018f-01.tar.gz
to
java -jar /app/tmp/tzupdater.jar -l file:///app/tmp/tzdata2018f-01.tar.gz
or even
java -jar tzupdater.jar -l https://github.com/lucasbasquerotto/my-projects/raw/master/tz/tzdata2018f-01.tar.gz
if you don't want to download it manually.
In the example in my repository it generates a Docker image, but you can use it without docker, with Java installed directly in your OS.
I executed the last example above on my local machine (that uses Oracle JDK) and the timezone was corrected successfully:
public static void main(String[] args) {
System.out.println("Date: " + new Date()); // prints correctly now
}
Just make sure that you aren't using some third-party library (like Joda Time) that uses timezone data hardcoded in its own jar (or generate a jar from the source with updated timezone data, like in https://www.joda.org/joda-time/tz_update.html).
Since tzdata2018g is already released with the fix provided in rearguard format, please use the rearguard tzdata bundle with -l option.
For tzdata2018g the command will look like this:
java -jar tzupdater.jar -l https://web.cs.ucla.edu/~eggert/tz/release/2018g/tzdata2018g-rearguard.tar.gz
Had the same issue here, and the problem seems to be just on the latest version.
Using
java -jar tzupdater.jar -l https://data.iana.org/time-zones/releases/tzdata2018d.tar.gz
(if "2018d" is enough for you) should work fine.
For some reason, after that, upgrading to the latest tzdata also worked fine (with just a warning).
I was running into the same error, then I fixed the downloaded file from IANA, using the following shell script, which replaces the troublesome line in the file by the previous version of "asia" file, as described by #lucas-basquerotto in his post below. I've tested and it works fine!
Please, download the TZUpdater bundle, extract the tzupdater.jar and update the variable TZUPDATER_JAR with the full file path of the downloaded jar file in order to run the script successfully.
#!/bin/bash
#FULL PATH TO tzupdater.jar
TZUPDATER_JAR='/home/user/tzupdater.jar'
OUTPUT_ALL=$(java -jar $TZUPDATER_JAR -l 2>&1 >/dev/null)
echo "$OUTPUT_ALL" | grep -e "Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000" > /dev/null
if [ $? -eq 0 ]
then
FIXME_FILE=$(echo "$OUTPUT_ALL" | grep -Po "(?<=java.lang.Exception: Failed while parsing file ').+(?=' on line 1655 'Rul)")
echo "file $FIXME_FILE contains a syntax error"
ERROR_LINE=$(sed -n '1656,1656p' $FIXME_FILE )
echo "Line 1655 \"$ERROR_LINE\" contains an error"
FIXED_LINE=${ERROR_LINE/Sat>=8/Sun>=9}
FIXED_LINE=${FIXED_LINE/25:00/0:00}
echo "Line 1655 fixed: \"$FIXED_LINE\" ( rule \"Sat>=8 25:00\" replaced by \"Sun>=9 0:00\" as it was used to be on previous version )"
sed -i "s/$ERROR_LINE/$FIXED_LINE/" $FIXME_FILE
TEMP_DIR_NAME=$(dirname $FIXME_FILE)
cd $TEMP_DIR_NAME
mkdir tzdata
mv tzdata.tar.gz tzdata/
cd tzdata/
echo "untar original tzdata.tar.gz"
tar -xf tzdata.tar.gz
rm tzdata.tar.gz
FIXME_FILENAME=$(basename $FIXME_FILE)
echo "replacing original $FIXME_FILENAME file"
rm $FIXME_FILENAME
cp ../$FIXME_FILENAME $FIXME_FILENAME
echo "building a new tar ball with the fixing"
tar -czf ../tzdata-updated.tar.gz *
echo "installing the updated tar file (requires elevation sudo)"
sudo java -jar $TZUPDATER_JAR -l "file:///$TEMP_DIR_NAME/tzdata-updated.tar.gz"
if [ $? -ne 0 ]
then
echo "something went wrong!"
exit 2
fi
fi
echo "installation successful!"
Save this is script under the name update_jdk_tzdata.sh and grant it permission to execute: chmod +x update_jdk_tzdata.sh and execute it ./update_jdk_tzdata.sh (it requires sudo in order to update JRE files)
Update your version of Java 8; the tzupdater tool just works in Java 8 update 181.
Use these commands:
sudo apt-get install oracle-java8-installer
sudo update-alternatives --config java
and choose the number *0 (automatic)
sudo update-alternatives --config javac
and choose the same *0.
If you already have the tzupdater only see the version of it that is already 2018
java -jar tzupdater.jar -V
If you are having problems with the Japanese version, you can use another link for Brazil.
java -jar tzupdater.jar -l https://data.iana.org/time-zones/releases/tzdata2018e.tar.gz
Related
I'm trying to update JVM's Time Zone info using TZUpdater 2.2.0.
> [root#local tzupdater-2.2.0]# java -jar tzupdater.jar -V
tzupdater version 2.2.0-b01
JRE tzdata version: tzdata2018d
tzupdater tool would update with tzdata version: tzdata2018f
So, I'm running the command below:
> [root#local tzupdater-2.2.0]# java -jar tzupdater.jar -l
However, I'm getting this error message:
Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_1/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:000S'
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_1/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S'
at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377)
at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191)
at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307)
at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153)
at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230)
at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634)
Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000
at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173)
at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210)
at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475)
at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399)
at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354)
... 5 more
I'm using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as the source for the tzdata bundle.
Edited - In addition, I'm using either Java(TM) SE Runtime Environment (build 1.8.0_66-b17) and OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13), meanwhile I have same reported problem using TZUpdater or ZIUpdater
Can anyone help me about this issue? Any comment will be appreciated.
Many thanks.
Yes, the rules for Japan in 1948-1951 changed in 2018f in an "interesting" way: officially, Japan's fall back occurred at 25:00 on Saturday, instead of 01:00 on the Sunday. That confused the Java time zone updater, as well as my own Noda Time project.
There's now a commit to avoid 25:00 in the "rearguard" format - the rearguard format is basically more conservative, avoiding things like Ireland's negative DST.
I would expect a 2018g release at some point reasonably soon, to include that fix. Assuming the tzupdater tool uses the rearguard appropriately, I'd expect that to sort things out. If you can possibly wait until then, I'd do so. Otherwise, use the -l flag on tzupdater to specify a different data source, e.g. for 2018e: https://data.iana.org/time-zones/releases/tzdata2018e.tar.gz
If you need to use version 2018f but not the Asia timezone you can use it from 2018e and the other files from 2018f.
I've created the file tzdata2018f-01.tar.gz in my repository https://github.com/lucasbasquerotto/my-projects/tree/master/tz for anyone that wants to avoid making these manual changes.
There is an example of using ziupdater when creating a docker image with OpenJDK, but if you use Oracle JDK you should be able to use almost the same code to use tzupdater changing
java -jar /app/tmp/ziupdater-1.0.1.2.jar -l file:///app/tmp/tzdata2018f-01.tar.gz
to
java -jar /app/tmp/tzupdater.jar -l file:///app/tmp/tzdata2018f-01.tar.gz
or even
java -jar tzupdater.jar -l https://github.com/lucasbasquerotto/my-projects/raw/master/tz/tzdata2018f-01.tar.gz
if you don't want to download it manually.
In the example in my repository it generates a Docker image, but you can use it without docker, with Java installed directly in your OS.
I executed the last example above on my local machine (that uses Oracle JDK) and the timezone was corrected successfully:
public static void main(String[] args) {
System.out.println("Date: " + new Date()); // prints correctly now
}
Just make sure that you aren't using some third-party library (like Joda Time) that uses timezone data hardcoded in its own jar (or generate a jar from the source with updated timezone data, like in https://www.joda.org/joda-time/tz_update.html).
Since tzdata2018g is already released with the fix provided in rearguard format, please use the rearguard tzdata bundle with -l option.
For tzdata2018g the command will look like this:
java -jar tzupdater.jar -l https://web.cs.ucla.edu/~eggert/tz/release/2018g/tzdata2018g-rearguard.tar.gz
Had the same issue here, and the problem seems to be just on the latest version.
Using
java -jar tzupdater.jar -l https://data.iana.org/time-zones/releases/tzdata2018d.tar.gz
(if "2018d" is enough for you) should work fine.
For some reason, after that, upgrading to the latest tzdata also worked fine (with just a warning).
I was running into the same error, then I fixed the downloaded file from IANA, using the following shell script, which replaces the troublesome line in the file by the previous version of "asia" file, as described by #lucas-basquerotto in his post below. I've tested and it works fine!
Please, download the TZUpdater bundle, extract the tzupdater.jar and update the variable TZUPDATER_JAR with the full file path of the downloaded jar file in order to run the script successfully.
#!/bin/bash
#FULL PATH TO tzupdater.jar
TZUPDATER_JAR='/home/user/tzupdater.jar'
OUTPUT_ALL=$(java -jar $TZUPDATER_JAR -l 2>&1 >/dev/null)
echo "$OUTPUT_ALL" | grep -e "Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000" > /dev/null
if [ $? -eq 0 ]
then
FIXME_FILE=$(echo "$OUTPUT_ALL" | grep -Po "(?<=java.lang.Exception: Failed while parsing file ').+(?=' on line 1655 'Rul)")
echo "file $FIXME_FILE contains a syntax error"
ERROR_LINE=$(sed -n '1656,1656p' $FIXME_FILE )
echo "Line 1655 \"$ERROR_LINE\" contains an error"
FIXED_LINE=${ERROR_LINE/Sat>=8/Sun>=9}
FIXED_LINE=${FIXED_LINE/25:00/0:00}
echo "Line 1655 fixed: \"$FIXED_LINE\" ( rule \"Sat>=8 25:00\" replaced by \"Sun>=9 0:00\" as it was used to be on previous version )"
sed -i "s/$ERROR_LINE/$FIXED_LINE/" $FIXME_FILE
TEMP_DIR_NAME=$(dirname $FIXME_FILE)
cd $TEMP_DIR_NAME
mkdir tzdata
mv tzdata.tar.gz tzdata/
cd tzdata/
echo "untar original tzdata.tar.gz"
tar -xf tzdata.tar.gz
rm tzdata.tar.gz
FIXME_FILENAME=$(basename $FIXME_FILE)
echo "replacing original $FIXME_FILENAME file"
rm $FIXME_FILENAME
cp ../$FIXME_FILENAME $FIXME_FILENAME
echo "building a new tar ball with the fixing"
tar -czf ../tzdata-updated.tar.gz *
echo "installing the updated tar file (requires elevation sudo)"
sudo java -jar $TZUPDATER_JAR -l "file:///$TEMP_DIR_NAME/tzdata-updated.tar.gz"
if [ $? -ne 0 ]
then
echo "something went wrong!"
exit 2
fi
fi
echo "installation successful!"
Save this is script under the name update_jdk_tzdata.sh and grant it permission to execute: chmod +x update_jdk_tzdata.sh and execute it ./update_jdk_tzdata.sh (it requires sudo in order to update JRE files)
Update your version of Java 8; the tzupdater tool just works in Java 8 update 181.
Use these commands:
sudo apt-get install oracle-java8-installer
sudo update-alternatives --config java
and choose the number *0 (automatic)
sudo update-alternatives --config javac
and choose the same *0.
If you already have the tzupdater only see the version of it that is already 2018
java -jar tzupdater.jar -V
If you are having problems with the Japanese version, you can use another link for Brazil.
java -jar tzupdater.jar -l https://data.iana.org/time-zones/releases/tzdata2018e.tar.gz
I am new to Linux system and there seem to be too many Java folders.
java -version gives me:
java version "1.7.0_55"
OpenJDK Runtime Environment (rhel-2.4.7.1.el6_5-x86_64 u55-b13)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
When I am trying to build a Maven project , I am getting error:
Error: JAVA_HOME is not defined correctly.
We cannot execute /usr/java/jdk1.7.0_05/bin/java
Could you please tell me which files I need to modify for root as well as not-root user and where exactly is java located?
find /usr/lib/jvm/java-1.x.x-openjdk
vim /etc/profile
Prepend sudo if logged in as not-privileged user, ie. sudo vim
Press 'i' to get in insert mode
add:
export JAVA_HOME="path that you found"
export PATH=$JAVA_HOME/bin:$PATH
logout and login again, reboot, or use source /etc/profile to apply changes immediately in your current shell
For all users, I would recommend creating a file in /etc/profile.d/java_home.sh the following lines
# Set JDK installation directory according to selected Java compiler
export JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:/bin/javac::")
This will update dynamically and works well with the alternatives system. Do note though that the update will only take place in a new login shell.
You could use /etc/profile or better a file like /etc/profile.d/jdk_home.sh
export JAVA_HOME=/usr/java/jdk1.7.0_05/
You have to remember that this file is only loaded with new login shells.. So after bash -l or a new gnome-session and that it doesn't change with new Java versions.
None of the other answers were "sticking" for me in RHEL 7, even setting JAVA_HOME and PATH directly in /etc/profile or ~/.bash_profile would not work. Each time I tried to check if JAVA_HOME was set, it would come up blank:
$ echo $JAVA_HOME
(<-- no output)
What I had to do was set up a script in /etc/profile.d/jdk_home.sh:
#!/bin/sh
export JAVA_HOME=/opt/ibm/java-x86_64-60/
export PATH=$JAVA_HOME/bin:$PATH
I initially neglected the first line (the #!/bin/sh), and it won't work without it.
Now it's working:
$ echo $JAVA_HOME
/opt/ibm/java-x86_64-60/
Open terminal and type sudo gedit .bashrc
It will ask you your password. After typing the password, it will open the bash file. Then go to end and type:
export JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/"
export PATH=$PATH:$JAVA_HOME/bin
Then save the file and exit from file
Above is for a single user. For all users, you have to follow below steps
gedit /etc/profile
export JAVA_HOME="/usr/lib/jvm/java-8-openjdk-amd64/"
export PATH=$PATH:$JAVA_HOME/bin
Copy the bin file path you installed
YOUR PATH
open terminal and edit environment file by typing following command,
sudo nano /etc/environment
In this file, add the following line (replacing YOUR_PATH by the just copied path):
JAVA_HOME="YOUR_PATH"
That should be enough to set the environment variable. Now reload this file:
source /etc/environment
now test it by executing:
echo $JAVA_HOME
Doing what Oracle does (as a former Sun Employee I can't get used to that one)
ln -s latestJavaRelease /usr/java/default
Where latestJavaRelease is the version that you want to use
then export JAVA_HOME=/usr/java/default
The answer is given previous posts is valid. But not one answer is complete with respect to:
Changing the /etc/profile is not recommended simply because of the reason (as stated in /etc/profile):
It's NOT a good idea to change this file unless you know what you are doing. It's much better to create a custom.sh shell script in
/etc/profile.d/ to make custom changes to your environment, as this
will prevent the need for merging in future updates.*
So as stated above create /etc/profile.d/custom.sh file for custom changes.
Now, to always keep updated with newer versions of Java being installed, never put the absolute path, instead use:
#if making jdk as java home
export JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:/bin/javac::")
OR
#if making jre as java home
export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:/bin/java::")
And remember to have #! /bin/bash on the custom.sh file
First you need to find out which Java is installed in your PC and which one to use.
For that open terminal with root permission.
sudo su
ls /usr/lib/jvm/
Now it will list the available java versions.
Select the listed version.
Copy the path till there.
Now open bashrc
nano ~/.bashrc
add the following commands to the end
export JAVA_HOME="path that you copied"
export PATH=$JAVA_HOME/bin:$PATH
after that save the file and exit by pressing Ctrl+S followed by Ctrl+X
Now run the below command:
source ~/.bashrc
1...Using the short cut Ctlr + Alt + T to open terminal
2...Execute the below command:
echo export JAVA_HOME='$(readlink -f /usr/bin/javac | sed "s:/bin/javac::")' | sudo tee /etc/profile.d/jdk_home.sh > /dev/null
3...(Recommended) Restart your VM / computer. You can use source /etc/source if don't want to restart computer
4...Using the short cut Ctlr + Alt + T to open terminal
5...Verified JAVA_HOME installment with
echo $JAVA_HOME
One-liner copy from flob, credit to them
This is a very simple script to solve the problem
export JAVA_HOME_BIN=`which java`
export JAVA_HOME_DIR=`dirname $JAVA_HOME_BIN`
export JAVA_HOME=`dirname $JAVA_HOME_DIR`
And for testing:
echo $JAVA_HOME
Posting as answer, as I don't have the privilege to comment.
Point to note: follow the accepted answer posted by "That Dave Guy".
After setting the variables, make sure you set the appropriate permissions to the java directory where it's installed.
chmod -R 755 /usr/java
All operational steps(finding java, parent dir, editing file,...) one solution
zFileProfile="/etc/profile"
zJavaHomePath=$(readlink -ze $(which java) | xargs -0 dirname | xargs -0 dirname)
echo $zJavaHomePath
echo "export JAVA_HOME=\"${zJavaHomePath}\"" >> $zFileProfile
echo "export PATH=\$PATH:\$JAVA_HOME/bin" >> $zFileProfile
Result:
# tail -2 $zFileProfile
export JAVA_HOME="/usr/lib/jvm/java-11-openjdk-11.0.7.10-1.el8_1.x86_64"
export PATH=$PATH:$JAVA_HOME/bin
Explanation:
1) Let's break the full command into pieces
$(readlink -ze $(which java) | xargs -0 dirname | xargs -0 dirname)
2) Find java path from java command
# $(which java)
"/usr/bin/java"
3) Get relative path from symbolic path
# readlink -ze /usr/bin/java
"/usr/lib/jvm/java-11-openjdk-11.0.7.10-1.el8_1.x86_64/bin/java"
4) Get parent path of /usr/lib/jvm/java-11-openjdk-11.0.7.10-1.el8_1.x86_64/bin/java
# readlink -ze /usr/bin/java | xargs -0 dirname
"/usr/lib/jvm/java-11-openjdk-11.0.7.10-1.el8_1.x86_64/bin"
5) Get parent path of /usr/lib/jvm/java-11-openjdk-11.0.7.10-1.el8_1.x86_64/bin/
# readlink -ze /usr/bin/java | xargs -0 dirname | xargs -0 dirname
"/usr/lib/jvm/java-11-openjdk-11.0.7.10-1.el8_1.x86_64"
Step 1 - check the current java version by "echo $JAVA_HOME"
Step 2 - vim /etc/profile
Step 3 - At the end of file you will find
export JAVA_HOME, we need to provide the new path here, make sure that it is not relative.
Step 4 - Save and exit :wq
Step 5 - "source /etc/profile/", this would execute the change
Step 6 - Again do a echo $JAVA_HOME - change would have been reflected.
Probably a good idea to source whatever profile you edit to save having to use a fresh login.
either:
source /etc/
or
. /etc/
Where is whatever profile you edited.
On Linux I add this line to my ~/.profile:
export JAVA_HOME=$(readlink -ze /usr/bin/javac | xargs -0 dirname -z | xargs -0 dirname)
While we are up to setting JAVA_HOME, let me share some benefits of setting JAVA_HOME or any other environment variable:
1) It's easy to upgrade JDK without affecting your application startup and config file which points to JAVA_HOME. you just need to download new version and make sure your JAVA_HOME points to new version of Java. This is best benefit of using environment variable or links.
2) JAVA_HOME variable is short and concise instead of full path to JDK installation directory.
3) JAVA_HOME variable is platform independence i.e. if your startup script uses JAVA_HOME then it can run on Windows and UNIX without any modification, you just need to set JAVA_HOME on respective operating system.
Read more: http://javarevisited.blogspot.com/2012/02/how-to-set-javahome-environment-in.html#ixzz4BWmaYIjH
Use SDKMAN sdkman.io to switch btw. your sdk's.
It sets the JAVA_HOME for you.
open kafka-run-class.sh with sudo to write
you can find kafka-run-class.sh in your kafka folder : kafka/bin/kafka-run-class.sh
check for these lines
Modify the JAVA variable in the else part to point to the java executable in your java/bin. like JAVA="$JAVA_HOME/java"
In /etc/profile , if you open that will you’ll get to know that IT IS no recommended to write on that file. Instead of that make a script of your commands(suppose test.sh)go to /etc/profile.d folder and Put test.sh there. Every time you instance reboot it’ll be automatically called by /etc/profile.
Using vim might be a bit difficult for new user. We can use gedit text editor instead.
Find /usr/lib/jvm/java-1.x.x-openjdk
Enter "gedit /etc/profile" or use "sudo gedit /etc/profile" if logged in as not-privileged
Add the following at the end of line:
export JAVA_HOME="path that you found"
export PATH=$JAVA_HOME/bin:$PATH
Enter "source /etc/profile" in your current shell to apply the changes
I use the line:
export JAVA_HOME=$(readlink -f $(dirname $(readlink -f $(which java) ))/../)
to my ~/.profile so it uses the base of the default java directory at login time. This is for bash.
Try this if doesn't work:
apt install openjdk-8-jdk-headless
I’m trying to install JDK on Centos, but I’m getting an error:
[root#www opt]# rpm -ivh /opt/jdk-7u51-linux-x64.rpm
Preparing... ########################################### [100%]
1:jdk ########################################### [100%]
error: unpacking of archive failed on file /usr/java/jdk1.7.0_51/db/lib/derbyLocale_zh_CN.jar;533ab42a: cpio: read
Where can be problem?
Thanks
Can you please check the md5sum of the downloaded file against these values here: http://www.oracle.com/technetwork/java/javase/downloads/java-se-binaries-checksum-1956892.html ?
If the md5sum does not check, it must be a broken download.
A short answer: try downloading and installing again.
A longer answer:
Even though you are getting this, the jdk is getting installed. Sort of. This seems to be an error in the packaging but it is not fatal. Here is the output from my machine. In the example I cat'd the release file so you can see what CentOS I'm using and did an md5sum on the rpm I'm using. You'll notice that it doesn't match the md5sum from the Oracle site link (provided above by Kristof).
Next, I did an ls on the target directory for the jdk /usr/java/ so you can see that it is empty. Then ran the rpm install and did another ls to show that some files are there.
Of course, this defeats the purpose of using rpm, because the install information is not going to go into the rpm database. If I query the database it doesn't come up and it's missing the links that usually get installed pointing to 'latest' and 'default'
So I took a guess that maybe there is a mirror that might have a bad rpm and went to the Oracle site and downloaded the file again. I gave it a different name so that I can compare the two files. This time it was successful.
In the screen shot below you can see the two files. The newest download being the one I called jdk-7u51-linux-x86_64.rpm. You can see the md5sum shows the files are different, but on the new file, the md5 matches the Oracle site. I removed the directory that was created by the failed install and then ran the rpm -ivh command and it completed successfully. The ls on the /usr/java directory shows all the correct stuff and querying the rpm database shows it was installed. Hope this helps!
You can do it with simple script which you can find here
It's for Centos rpm, but you can edit script and change rpm to tar.gz for example
Also you can change version or env in variables bellow
BASE_URL="technetwork/java/javase/downloads"
BASE_URL_OUTPUT="$(curl -s -L0 http://www.oracle.com/${BASE_URL}/)"
JAVA_ENVIRONMENT="JDK"
JAVA_BASE_VERSION=8
DOWNLOAD_SITE="$(echo $BASE_URL_OUTPUT | grep -m 1 -io "${JAVA_ENVIRONMENT}${JAVA_BASE_VERSION}-downloads-[0-9]*.html" -- | tail -1)"
echo "DOWNLOAD_SITE="$DOWNLOAD_SITE
DOWNLOAD_LINK_OUTPUT="$(curl -s -L -j -H "Cookie: oraclelicense=accept-securebackup-cookie" http://www.oracle.com/${BASE_URL}/${DOWNLOAD_SITE} | grep -io "filepath.*${JAVA_ENVIRONMENT}-[${JAVA_BASE_VERSION}].*linux[-_]x64[._].*\(rpm\)" -- | cut -d '"' -f 3 | tail -1)"
echo "DOWNLOAD_LINK_OUTPUT="$DOWNLOAD_LINK_OUTPUT
curl -L -o java_rpm_packet.rpm -b "oraclelicense=a" $DOWNLOAD_LINK_OUTPUT
and install with
yum localinstall -y java_rpm_packet.rpm
alternate --config is updated
java -version works
How do i verify if java is installed if java is installed and what version. What is the correct way.
I think this is what you want:
#!/bin/bash
if [ -x /usr/bin/java ] ; then
java -version 2>&1 | head -1 | awk -F '"' '{print $2}'
else
exit
fi
OUTPUT (on my linux box):
1.6.0_18
check whether the java executable is present. if yes, then print the version.
I hope the following code may help you, please try it,
a=`(java -version) 2>&1`
if [[ "$a" == *1.7* ]]
then
echo '1.7'
fi
Depends on how you expect it to be installed; there are two ways to find the java binary:
look for java in PATH (which is what you're doing by executing java -version)
if JAVA_HOME is defined, treat that as the preferred installation and run $JAVA_HOME/bin/java -version
After that, just extract the version number from the output as you need (see slayedbylucifer's answer above).
Is there any linux command I could use to find out JAVA_HOME directory? I've tried print out the environment variables ("env") but I can't find the directory.
On Linux you can run $(dirname $(dirname $(readlink -f $(which javac))))
On Mac you can run $(dirname $(readlink $(which javac)))/java_home
I'm not sure about windows but I imagine where javac would get you pretty close
Just another solution, this one's cross platform (uses java), and points you to the location of the jre.
java -XshowSettings:properties -version 2>&1 > /dev/null | grep 'java.home'
Outputs all of java's current settings, and finds the one called java.home.
For windows, you can go with findstr instead of grep.
java -XshowSettings:properties -version 2>&1 | findstr "java.home"
echo $JAVA_HOME will print the value if it's set. However, if you didn't set it manually in your startup scripts, it probably isn't set.
If you try which java and it doesn't find anything, Java may not be installed on your machine, or at least isn't in your path. Depending on which Linux distribution you have and whether or not you have root access, you can go to http://www.java.com to download the version you need. Then, you can set JAVA_HOME to point to this directory. Remember, that this is just a convention and shouldn't be used to determine if java is installed or not.
I know this is late, but this command searches the /usr/ directory to find java for you
sudo find /usr/ -name *jdk
Results to
/usr/lib/jvm/java-6-openjdk
/usr/lib/jvm/java-1.6.0-openjdk
FYI, if you are on a Mac, currently JAVA_HOME is located at
/System/Library/Frameworks/JavaVM.framework/Home
To show the value of an environment variable you use:
echo $VARIABLE
so in your case will be:
echo $JAVA_HOME
In case you don't have it setted, you can add in your .bashrc file:
export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::")
and it will dynamically change when you update your packages.
If $JAVA_HOME is defined in your environment...
$ echo $JAVA_HOME
$ # I am not lucky...
You can guess it from the classes that are loaded.
$ java -showversion -verbose 2>&1 | head -1
[Opened /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75.x86_64/jre/lib/rt.jar]
This method ensures you find the correct jdk/jre used in case there are multiple installations.
Or using strace:
$ strace -e open java -showversion 2>&1 | grep -m1 /jre/
open("/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.75.x86_64/jre/bin/../lib/amd64/jli/tls/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
On the Terminal, type:
echo "$JAVA_HOME"
If you are not getting anything, then your environment variable JAVA_HOME has not been set. You can try using "locate java" to try and discover where your installation of Java is located.
Did you set your JAVA_HOME
Korn and bash shells:export JAVA_HOME=jdk-install-dir
Bourne shell:JAVA_HOME=jdk-install-dir;export JAVA_HOME
C shell:setenv JAVA_HOME jdk-install-dir
Here's an improvement, grabbing just the directory to stdout:
java -XshowSettings:properties -version 2>&1 \
| sed '/^[[:space:]]*java\.home/!d;s/^[[:space:]]*java\.home[[:space:]]*=[[:space:]]*//'
You can check from the command line by executing this command echo $JAVA_HOME. If Java is installed but the path is not set, you need to identify the path to your java installation. I prefer using sudo update-alternatives --config java which lists all installed versions with current active one marked and provides dialog to switch:
There are 3 programs which provide 'java'.
Selection Command
-----------------------------------------------
1 java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.14.0.9-2.fc35.x86_64/bin/java)
2 java-17-openjdk.x86_64 (/usr/lib/jvm/java-17-openjdk-17.0.2.0.8-1.fc35.x86_64/bin/java)
*+ 3 /usr/java/jdk-17.0.2/bin/java
Enter to keep the current selection[+], or type selection number:
from the above list, you can select the version of java you want to be the default. To set the JAVA_HOME to option 3 for instance you can do it this way export JAVA_HOME=/usr/java/jdk-17.0.2
http://www.gnu.org/software/sed/manual/html_node/Print-bash-environment.html#Print-bash-environment
If you really want to get some info about your BASH put that script in your .bashrc and watch it fly by. You can scroll around and look it over.