I have both Java JRE and Java JDK on a FreeBSD 7.2 box (running PFSense) from http://www.freebsdfoundation.org/downloads/java.shtml
find / -name gives me output like:
/usr/local/diablo-jre1.6.0/bin/java
/usr/local/diablo-jdk1.6.0/bin/java
/usr/local/diablo-jdk1.6.0/jre/bin/java
so I make a link to /usr/local/bin like so:
ln /usr/local/diablo-jre1.6.0/bin/java /usr/local/bin/java
and now I get
# rehash
# java
Error: could not find libjava.so
Error: could not find Java 2 Runtime Environment.
SOOOOOO, I'm wondering if there is some tool I can use to turn on a particular java vm similar to Ubuntus' /etc/jvm?
The /usr/local/diablo-jre1.6.0/bin/java application probably locates libjava.so relative to the location of the java application itself. By creating a hard link to java and executing it via that hard link, you've probably broken that mechanism.
Suggestions:
Put /usr/local/diablo-jre1.6.0/bin on your search path.
Create an alias for java instead of a link.
Replace the hard link with a symbolic link; i.e. use ln -s to create it.
The FreeBSD packages should have installed a wrapper-script in /usr/local/bin/java that knows about the different installed JVMs, and their JAVA_HOMEs etc. Did you by chance accidentally download the tarball instead of the package?
What does pkg_info | grep jdk yield?
If this is in a jail, you may need to move /proc temporarily so it doesn't try to use it to find out where the Java libraries are. Got bitten by this one!
Related
I do not wish to change my host's notion of what Java is, only download one or more JDKs including OpenJDK. I need to test and compare JDKs as part of a build system.
Just as I am able to download and then not install Oracle JDK with no problem, I need to download and not install a copy of open JDK. The website http://openjdk.java.net/install/index.html doesn't offer this possibility.
Has anyone found a solution to this?
The easiest way to do that would be to download OpenJDK source code and build it. For 8, it basically boils down to cloning the right set of trees and then doing the regular build steps:
cd /path/to/where/you/cloned/jdk8u
mkdir build
bash ../configure # not ../configure because configure is not marked as executible
make all
Look under build/ and search for a j2sdk-image directory. That's your jdk:
cp -a build/images/j2sdk-image /location/where/i/put/my/jdks/
The distribution packages of OpenJDK often include various changes that make it not suitable for moving around (liked tweaked RPATHs). That said, if you are feeling up to the risk, you can do something like:
yum --download-only install 'java-1.8.0-openjdk*'
Now you have a bunch of RPMs. Extract them manually:
rpm2cpio ./name.of.rpm.x86_64.rpm | cpio -id
You should see usr and other fumnny looking directories in the current working directory. Go through the, find the OpenJDK dir and move it over to some other location. For example:
cp -a usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b16.fc24.x86_64/ /location/where/i/put/my/jdks/
Note that it's usr/, not /usr/. Strip non-$ORIGIN RPATHs if you see on any ELF files.
Something similar probably exists for Debian/Ubuntu, but I am not familiar with them.
A user of my software is running Windows with Cygwin installed, which provides access to the standard GNU which command. In my CMakeLists.txt there is a line that reads:
FIND_PACKAGE( JAVA REQUIRED CONFIG )
This fails on his machine, because both JAVAConfig.cmake and java-config.cmake (executed by FIND_PACKAGE) use this command as a first-line attack in locating Java. The command returns a bad path to a non-existent install of Java. What can I do to override this annoying behavior from my CMakeLists.txt?
Ask him to send you his "path" env. variable, you will find something interesting there for sure.
Other issue is Java installations.
Ask him to unstall old javas or just update to newest, current installer removes older copies.
I try to use the sun grid engine with the DRMAA api by following the tutorial found at: http://gridscheduler.sourceforge.net/howto/drmaa_java.html. For this I need to load the c library located in /srv/sge/lib/lx24-amd64/drmaa.so. Now I execute my command with this code: java -jar scriptName.jar -Dshared.library.path=/srv/sge/lib/lx24-amd64/ as described in https://blogs.oracle.com/templedf/entry/drmaa_and_the_shared_library. But still I get the this exception:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no drmaa in
java.library.path
This exception is thrown when trying to retrieve the session:
session = SessionFactory.getFactory().getSession();
OS is linux 64 bit, java is 64 bit and SGE is 64 bit, so this is all compatible.
Does anyone know what is going wrong?
You will want to change shared.library.path to java.library.path (I believe that is a mistake in the blog post you referenced.
Also, place the -D switch before the -jar switch in your command, otherwise it is interpreted as an argument to the main function in the jar file rather than an argument to the JVM.
So, your example command should now look like this:
java -Djava.library.path=/srv/sge/lib/lx24-amd64/ -jar scriptName.jar
The case seems to be that in some distributions the libdrmaa.so has a library version number libdrmaa.so.1.0 while the libdrmaa.so without version number is missing. The drmaa.jar seems to just look for the one without. You can check which of the libdrmaa.so libraries are available in your system using
# ldconfig -p | grep libdrmaa
Which (in my case) either says
libdrmaa.so.1.0 (libc6,x86-64) => /lib64/libdrmaa.so.1.0
or
libdrmaa.so.1.0 (libc6,x86-64) => /lib64/libdrmaa.so.1.0
libdrmaa.so (libc6,x86-64) => /lib64/libdrmaa.so
The second case is the good one!
For Fedora distributions I reported this as a bug and it seems that they fix it in F18 and F19 soon. https://bugzilla.redhat.com/show_bug.cgi?id=671880
It is an easy fix in Fedora to simply install the package "gridengine-devel" where this soft-link is included.
If the libdrmaa.so without version number is not there and you are on another distribution, you can fix it manually as system administrator by typing
# cd /usr/lib64
# sudo ln -sf libdrmaa.so.1.0 libdrmaa.so
# sudo ldconfig
None of the previous answers worked for me. I've managed to solve this problem defining in my environment the following variable
export LD_LIBRARY_PATH=<path to the drmaa lib>
I have read this article
http://lifehacker.com/5354441/google-docs-batch-upload-eases-online-document-transfers
java -jar google-docs-upload-1.2.jar /home/kevin/uploads --recursive
now its not working it says bas command not found.
is java already installed in vps centos or i have to install it
Either you don't have java or its not available in your path. Some linux distros install java in the /opt directory. So be sure to check if that's the case with you. If so then its just a matter of updating your path if not then there are two possibilities :
1. You have root access.
2. You don't have root access.
If you do have root access then you can easily install java with your package manager, if now you can still install java as a local user. Read this to do that. You can install any version of java that you so wish, also it may be unnecessary to install JDK, just JRE might be enough for you.
Don't do the steps that need root access, just copy it somewhere in your home directory or any of the directories to which you have access. Then set the appropriate values for JAVA_HOME and your PATH. It should work then.
If you need any help in doing that feel free to ask.
Download the jar google-docs-upload-1.2.jar.
Ensure you have Java.
Use your own home- and upload-folder, not the "kevin/uploads" one.
I have Ubuntu 10.10 with java already installed. I am able to execute java command from any folder. I supposed that could be because I had java Classpath setted. But neither JAVA_HOME nor CLASSPATH are setted.
If I look at /etc/environment content I can see that PATH is setted to /usr/bin/ (among others). As 'which java' returns /usr/bin/java, is that the reason why I can execute java from anywhere? If not, why is it?
You can execute java because the command is on your path.
echo $PATH
will show you which directories are searched, in which order to find a particular program. Since /usr/bin is on your path, when you type java it will eventually look at /usr/bin/java. Note that in many systems this is a symbolic link (a file that points to another file) so /usr/bin/java often points to /etc/alternatives/java (which is also a symbolic link that points to the real executable).
Where the environmental variable JAVA_HOME comes into play is in tools and programs that check for JAVA_HOME and act on it instead of relying on the path. In most modern Linux systems, the work done by the alternatives subsystem replaces the earlier (more problematic) JAVA_HOME technique. That said, you might want to set JAVA_HOME anyway, should you encounter a tool that demands it.
One reason why JAVA_HOME is not as popular as it could be is that to access JAVA_HOME you need to run a shell, and not everyone wants to wrap every single Java item in a shell command.
Yes, if java binary (or a link to it) is on a folder that is listed on the path then you can execute java without specifying the path to it (for example /usr/local/java/latest/bin/java -jar x.jar)
JAVA_HOME and CLASSPATH have nothing to do with system path.
JAVA_HOME allow other software (or scripts) to know where to look for java installation.
CLASSPATH tells java where to look for classes (.class files resulting of compiling .java files).