On Windows I noticed that the java binary is in two different locations (I have the JDK installed):
C:\Program Files\Java\jdk1.8.0_121\bin\java.exe
C:\Program Files\Java\jdk1.8.0_121\jre\bin\java.exe
Similarly on a Unix box that I have access to, there are two copies, one in jre/bin and one just in bin. I am not sure if this other one is the JDK or just a JRE installation.
In both cases, they are the same size as each other. I confirmed they aren't symlinked on the Linux side although I suppose they could be hard linked.
The contents of jdk/bin/ is the Java binaries that are included with the Java Developers Kit. The Java binaries inside of jdk/jre/bin are the Java Runtime Environment's binaries.
If you have the JDK version of Java then use the one in jdk/bin/.
But they are the same
If you look at the executables there is actually no difference in them, so it really doesn't matter.
$ pwd
/usr/java/jdk1.7.0_45
$ ll jre/bin/java
-rwxr-xr-x. 1 root root 7718 Oct 8 2013 jre/bin/java
[saml#greeneggs jdk1.7.0_45]$ ls -l bin/java
-rwxr-xr-x. 1 root root 7718 Oct 8 2013 bin/java
$ cmp jre/bin/java bin/java
$
Related
I'm using RHEL8 which has default OpenJDK installed.
which java command points to /usr/bin/java.
java -version gives openjdk version "1.8.0_252"
Installed java in /u01/app/java/ location. Modified the .bashrc like below & sourced it.
export JAVA_HOME=/u01/app/java/jdk1.8.0_241/
PATH="$JAVA_HOME/bin/java:$HOME/.local/bin:$HOME/bin:$PATH"
export PATH
Now JAVA_HOME points to /u01/app/java/jdk1.8.0_241/ But which java or java -version still points to the OpenJDK.
Added the same in .bash_profile file & removed it from the .bashrc : Results are same
Deleted OpenJDK & made changes in .bash_profile. But by doing so ended up with "Command not found" error.
How can i fix it?
It was Path issue.
I have given PATH="$JAVA_HOME/bin/java:$HOME/.local/bin:$HOME/bin:$PATH" for PATH. which should not be the case.
Modified my PATH to below. It worked.
PATH="$JAVA_HOME/bin:$HOME/.local/bin:$HOME/bin:$PATH"
export PATH
That happens because when you invoke java it is actually invoked /usr/bin/java, which, issuing ls -l /usr/bin/java you will probably see is linked to the openjdk installation (probably through a double link: the first one being /usr/bin/java to /etc/alternatives/java and the second one being the link to the "real" java executable). For example, on my debian:
gianluca#asus-debian:~$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 mag 20 2018 /usr/bin/java -> /etc/alternatives/java
gianluca#asus-debian:~$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 43 nov 22 2019 /etc/alternatives/java -> /usr/lib/jvm/java-11-openjdk-amd64/bin/java
You can fix in two ways:
Dirty way, you manually update all the symbolic links in /usr/bin that lead to the unwanted java version and make them point to the desired one
Clean way, you use alternatives that does the job for you.
You can read more about alternatives for RHEL here (mid-page... "The longer version").
Good link
I installed the release version of JDK 9 on Mac OS.
jshell works great, Jigsaw module support works, but there is no jlink:
➜ java --version
java 9
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
This comes up empty:
find /System/Library/Frameworks/JavaVM.framework/Versions/Current/ -iname jlink\*
FYI:
➜ ls -l $(which java)
lrwxr-xr-x 1 root wheel 74 Nov 7 2016 /usr/bin/java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
You can verify your JAVA_HOME using which java and make sure it points to the default installation path which ideally should be
/Library/Java/JavaVirtualMachines...
[for e.g. I use it as export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/]
and further you can find the jlink in the bin folder of Contents
find /Library/Java/JavaVirtualMachines/jdk-9.jdk -iname jlink\*
which should return
/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin
Attaching a screenshot for reference of the location its installed:-
Note: Though in the screenshot, the command doesn't run successfully but its recognized.
To add the JDK 9 tools to your path, add the following to the file .bashrc of your home directory:
export JAVA_HOME=$(/usr/libexec/java_home -v 9)
export PATH="$JAVA_HOME/bin:$PATH"
Did you notice the -v 9? you can change that to 1.8 if you ever want to switch back to JDK 1.8. For any newbie who can’t locate .bashrc in the Finder: press ⌘⇧. (command shift dot) to reveal hidden files.
There's some important context here: Understanding Oracle's Java on Mac
The standard JDK utilities (java, javac, etc) are actually installed at /Library/Java/JavaVirtualMachines/(JDK_VERSION)/Contents/Home/bin.
/usr/bin is in the path, and in that directory you'll find all the usual JDK utilities. When you type java (or any other command), those are the ones it finds, but they are actually symlinks to executables with the same names in /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands. Those executables are just wrappers that interrogate your JAVA_HOME environment variable (which should point to the actual install location) and invoke the real binaries found there. I'm unclear on why anyone thought these two layers of abstraction were necessary, but it is what it is.
At some point after the release of Java 9, symlinks and wrappers for jshell were added to macOS, but it appears that no such thing was done for jlink.
To keep things working consistently going forward, I'd recommend writing an equivalent wrapper, putting it in the right location, and added a symlink to it in /usr/bin.
Unfortunately, since the wrapper scripts are under /System, you cannot create or modify anything, even as root, until you disable System Integrity Protection. This takes a few minutes and involves a few reboots, but it's easy to do:
Reboot your machine. While it reboots, hold down ⌘R. This will cause the machine to start up in Recovery Mode. You can release the keys when you see the progress bar.
Once in Recovery Mode, choose Terminal from the Utilities menu.
At the prompt, type csr disable. You'll be prompted to reboot to cause the changes to take place. Do that as well.
Once you're back in regular mode, open Terminal and do the following:
% sudo vi /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jlink
Password:
Enter your password at the prompt.
In vi, switch to Insert mode by pressing I, then enter the following text:
#!/bin/bash
$JAVA_HOME/bin/jlink $#
Then exit Insert mode by pressing esc, and save and exit by typing :wq.
Issue the following commands to make the script executable, create the symlink, make the symlink executable, and check your work:
% sudo chmod +x /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jlink
% sudo ln -s /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jlink /usr/bin/jlink
% sudo chmod +x /usr/bin/jlink
% ls -la $(which jlink)
lrwxr-xr-x 1 root wheel 75B Jun 19 10:33 /usr/bin/jlink# -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jlink
% ls -la $(which java)
lrwxr-xr-x 1 root wheel 74B Sep 25 2017 /usr/bin/java# -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
% jlink --version
10.0.1
%
Now it's time to re-enable System Integrity Protection. Reboot back into Recovery Mode (instructions in step 1).
Once in Recovery Mode, choose Terminal from the Utilities menu.
At the prompt, type csr enable. You'll be prompted to reboot once more.
If you'd rather not muck with disabling/re-enabling SIP, you can just create the script at /usr/bin/jlink.
Hopefully some future version of macOS will include these by default.
I am working on an java component which need some libraries i.e .dll for windows system and .so files for Linux system. So I prepared an java application in netbeans and added some dependency jars and build the project.
Execution on Windows:
When I tried to run jar file on Windows system using command java -jar appName.jar I got java.lang.UnsatisfiedLinkError so I specified java.library.path while execution like java -Djava.library.path=full\\path\\to\\libs -jar appName.jar and it got run successfully on Windows.
Execution on Linux(ubuntu) :
When I tried to execute same jar file on ubuntu with the same command java -Djava.library.path=/path/to/libs -jar appName.jar I got error saying some .so file are not found on specified location (I checked file location and permissions, all is ok)
Updated (added error):
ubuntu#ubuntu-HP-dx2480-MT-KL969AV:~/Desktop$ java
-Djava.library.path=/home/ubuntu/Desktop/bin -jar JavaApplication4.jar
initialize on Thread[AWT-EventQueue-0,6,main] with library path bin
bin/jcef_helper: error while loading shared libraries: libcef.so:
cannot open shared object file: No such file or directory
contains of bin folder
-rwxr-xr-x 1 ubuntu ubuntu 1483321 Jun 18 2014 cef.pak
-rwxr-xr-x 1 ubuntu ubuntu 3258231 Jun 18 2014 devtools_resources.pak
-rwxr-xr-x 1 ubuntu ubuntu 971264 Jun 11 2014 ffmpegsumo.dll
-rwxr-xr-x 1 ubuntu ubuntu 9994752 Jun 11 2014 icudt.dll
-rwxr-xr-x 1 ubuntu ubuntu 429568 Jun 18 2014 jcef.dll
-rwxr-xr-x 1 ubuntu ubuntu 481488 Jun 18 2014 jcef_helper
-rwxr-xr-x 1 ubuntu ubuntu 233984 Jun 18 2014 jcef_helper.exe
-rwxr-xr-x 1 ubuntu ubuntu 53280768 Jun 11 2014 libcef.dll
-rwxr-xr-x 1 ubuntu ubuntu 105317136 Jun 18 2014 libcef.so
-rwxr-xr-x 1 ubuntu ubuntu 1309288 Jun 18 2014 libffmpegsumo.so
-rwxr-xr-x 1 ubuntu ubuntu 1047296 Jun 18 2014 libjcef.so drwxrwxrwx 2 ubuntu ubuntu 4096 Dec 23 11:29 locales
By some searching I come to know that I have try with LD_LIBRARY_PATH environment variable so I created an sh file having command:
export LD_LIBRARY_PATH=/path/to/libs
java -jar /path/to/appName.jar
and when I run sh file my program runs successfully.
So my question is why java.library.path is not works for ubuntu (linux)? Is it like java.library.path is only for windows?
So my question is why java.library.path is not works for ubuntu (linux)? Is it like java.library.path is only for windows?
It does work, we use it a lot. Start your application with -XshowSettings:properties and take a look at the search path for debugging.
We usually deploy the libraries as a package to /usr/local/lib, since the libraries are often used by other components too. Don't forget to call ldconfig after placing a new library in there (so much for the export LD_LIBRARY_PATH part).
As far as i remember it should be enough with just adding the folder with -Djava.library.path if i recall correctly. I will look into it and tell you later to clarify.
Also please post readlink -f /home/ubuntu/Desktop/bin, file /home/ubuntu/Desktop/bin/libcef.so and ldd /home/ubuntu/Desktop/bin/libcef.so.
Update:
I will try to explain why things work and why not.
Lets talk about java.library.path. This property is used by the VM for looking up libraries. Take a look at java.lang.System#load*(String libName) for reference. The java.library.path property has some paths pre-set, the following shows the output on my ubuntu box:
ortang#vbox-devel:~$ java -XshowSettings:properties
Property settings:
...
java.library.path = /usr/java/packages/lib/amd64
/usr/lib/x86_64-linux-gnu/jni
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/jni
/lib
/usr/lib
Be aware that using this property will overwrite the existing property.
ortwin#vbox-devel:~$ java -Djava.library.path=/some/other/folder:/yet/another/one -XshowSettings:properties
Property settings:
...
java.library.path = /some/other/folder
/yet/another/one
So far so good. The JVM is looking only in the folders defined in that property!
The libraries you make the JVM to load will most likely have dependencies to other libraries. Be aware that these dependencies are looked up by the operating system, just as any other shared library!
So to solve your problem you have to make sure that the libraries you load have their dependencies resolved! Use ldd for debugging that matter.
The LD_LIBRARY_PATH environment variable does a similar job, as it adds paths that will be used for library lookup by the OS. I am no fan of using it in production environments.
My best guess for your problem is that you have to use both java.library.path and LD_LIBRARY_PATH. Indeed, j.l.p is for java to load you JNI library while L_L_P is for the operating system to load the shared library and any dependent libraries. If your shared library depends on other libraries in other paths you have to list those paths.
it's seem that jcef did not find it's depenencies, try ldd libcef.so |grep "not found" and ldd libjcef.so |grep "not found" and fix the missing libraries. On my machine (ubuntu 14.04) It miss libudev.so.0 , my machine has /lib/x86_64-linux-gnu/libudev.so.1 so trick it by ln -s /lib/x86_64-linux-gnu/libudev.so.1 /lib/x86_64-linux-gnu/libudev.so.0 and sudo ldconfig to reload ld cache.
I meet the same problem, I use "-Djava.library.path", but it does't work.
I add "-Dsun.boot.library.path" as a try, it works!
try:
java -Dsun.boot.library.path=/path/to/libs -jar appName.jar
I want to start my tomcat with a different java version than the "standard one". On my server java 6 is installed (java -version returns: java version "1.6.0_34")
I also downloaded a java 7 jdk and put it to /opt/oracle/7/jdk1.7.0_55/ and wanted my tomcat to run with java 7. So I added export JAVA_HOME=/opt/oracle/7/jdk1.7.0_55 to my script /etc/init.d/tomcat7.
When I try to start my tomcat via sudo /etc/init.d/tomcat7 start I get /opt/tomcat7/bin/catalina.sh: 1: eval: /opt/oracle/7/jdk1.7.0_55/bin/java: not found
But when I type ll /opt/oracle/7/jdk1.7.0_55/bin I get -rwxr-xr-x 1 root root java* So the path should be correct!?
I can't figure out why it doesn't work. Any hints appreciated. :-)
EDIT:
I probably just downloaded the wrong jdk (32 bit instead of 64)
You probably downloaded the wrong JDK. From your comments, it seems to be a 32bit JDK. If you have a 64bit Linux, then you can't load the executables.
uname -m tells you the architecture of your system. It should be i686 or i586 but probably is x86_64.
I know it's installed because when I type:
$java -version
I get:
OpenJDK Runtime Environment (IcedTea6 1.12.5) (6b27-1.12.5-0ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
And when I type:
$locate jdk
I get:
/home/arturo/Documents/2012a/sys/java/jre/glnxa64/jre/lib/servicetag/jdk_header.png
/usr/share/app-install/desktop/openjdk-6-jre:openjdk-6-java.desktop
/usr/share/app-install/desktop/openjdk-7-jre:openjdk-7-java.desktop
/usr/share/app-install/icons/openjdk-6.png
/usr/share/app-install/icons/openjdk-7.png
What worries me about the first item in the list is that the 2012a folder is my MATLAB folder and not a standard 'usr/lib' folder. I'm really confused on where the JDK and JRE got installed, because I need to set the $JAVA_HOME path pointing to the folder. Where am I missing something?
WAY-1 : Updated for the shortest and easy way
Below command will give you the path, But it will only work if java command is working in other words if java path is configured.
readlink -f $(which java)
Read more at Where can I find the Java SDK in Linux?
WAY-2 (Better than WAY-1) : Below answer is still working and try it if above command is not working
for you.
You need to dig into symbolic links. Below is steps to get Java directory
Step 1:
$ whereis java
java: /usr/bin/java /etc/java /usr/share/java
That tells the command java resides in /usr/bin/java.
Dig again:
Step 2:
$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 2009-01-15 18:34 /usr/bin/java -> /etc/alternatives/java
So, now we know that /usr/bin/java is actually a symbolic link to /etc/alternatives/java.
Dig deeper using the same method above:
Step 3:
$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 31 2009-01-15 18:34 /etc/alternatives/java -> /usr/local/jre1.6.0_07/bin/java
So, thats the actual location of java: /usr/local/jre.....
You could still dig deeper to find other symbolic links.
Reference : where is java's home dir?
Please use this command:
readlink -f $(which java)
It works for me with Ubuntu gnome.
On my computer the result is:
/usr/lib/jvm/java-7-oracle/jre/bin/java
Regards.
In generally, java gets installed at /usr/lib/jvm . That is where my sun jdk is installed. check if it is same for open jdk also.
$whereis java
java: /usr/bin/java /usr/bin/X11/java /usr/share/java /usr/share/man/man1/java.1.gz
$cd /usr/bin
$ls -l java
lrwxrwxrwx 1 root root 22 Apr 15 2014 java -> /etc/alternatives/java
$ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 39 Apr 15 2014 /etc/alternatives/java -> /usr/lib/jvm/java-7-oracle/jre/bin/java
So,JDK's real location is /usr/lib/jvm/java-7-oracle/
Location of JRE in Ubuntu:
/usr/lib/jvm/java-7-oracle/jre
$ whereis java
java: /usr/bin/java /usr/lib/java /usr/bin/X11/java /usr/share/java /usr/share/man/man1/java.1.gz
On Ubuntu 14.04, it is in /usr/lib/jvm/default-java.
For me, on Ubuntu, the various versions of JDK were in /usr/lib/jvm.
I found the solution to this with path name:
/usr/lib/jvm/java-8-oracle
I'm on mint 18.1
I am using Ubuntu 18.04.1 LTS. In my case I had to open the file:
/home/[username]/netbeans-8.2/etc/netbeans.conf
And change the jdk location to:
netbeans_jdkhome="/opt/jdk/jdk1.8.0_152"
Then saved the file and re-run Netbeans. It worked for me.
you can simply write the following command in the terminal of your linux system and get the java path :- echo $JAVA_HOME
The easiest way to do so is by typing echo $JAVA_HOME on your terminal.