Różności …

java.library.path is the path that Java uses to find native libraries (such as lwjgl.dll). You should set it to the directory that contains the DLL files. You specify this with the -D switch on the command line, for example:

java -Djava.library.path=C:\Java\ljwgl\libs org.mypackage.MyProgram

http://fedoraproject.org/wiki/Java

Type the full pathname of a J2SE installation (or Ctrl-C to quit), the path will be stored in ~/.sqldeveloper/jdk
/usr/lib/jvm/java

Maintaining Multiple Java Versions on Red Hat Linux

I had the need to maintain more than one Java version on a Red Hat Linux machine.  I was able to install a new version of Java, and then configure the machine to use the new version by default.  It’s also very easy to switch back to using the previous version of Java.

The first step is to download the Java version that you want from the Oracle/Java web site.  In my case, I downloaded the following file.

Executing this file as root will perform the installation.  You’ll, of course, have to make the file executable after download.  By default, the installation “wanted” to install Java in the following directory.

I still wanted to make the new installation the default Java used by the machine.  Linux has a nice utility called alternatives to do this, and more specifically, the update-alternatives command.  With this command, I was able to first register the newly installed Java as a version of Java that would be recognized by the utility, and I was then able to use the utility to make the new version of Java the default version.  When I used the utility to make the newly installed Java the default, the /usr/bin/java on the machine was modified to point to the new version.

Here is the script that I used to have the new version of Java recognized by the alternatives utility.

JAVA_HOME=/usr/java/jre1.6.0_27

# The following command added the new java installation as a java alternative.
# The slave commands bring the related commands with it.
update-alternatives \
–install /usr/bin/java java $JAVA_HOME/bin/java 1 \
–slave /usr/bin/javac javac $JAVA_HOME/bin/javac \
–slave /usr/bin/javadoc javadoc $JAVA_HOME/bin/javadoc \
–slave /usr/bin/jar jar $JAVA_HOME/bin/jar \
–slave /usr/bin/keytool keytool $JAVA_HOME/bin/keytool \
–slave /usr/local/java java_home $JAVA_HOME

# A web site suggested that these steps would also be required, but they were not
#ln -s /etc/alternatives/java /usr/bin/java
#ln -s /etc/alternatives/javac /usr/bin/javac
#ln -s /etc/alternatives/javadoc /usr/bin/javadoc
#ln -s /etc/alternatives/jar /usr/bin/jar
#ln -s /etc/alternatives/keytool /usr/bin/keytool
#ln -s /etc/alternatives/java_home /usr/local/java

It’s important to make sure that JAVA_HOME is set to point to the new installation directory.  The update-alternatives command links multiple Java utility programs together so that when you switch from one Java version to the next, the proper versions of the related tools come with it (note the slave option in the script above).  One web site I visited indicated that I would have to update symbolic links, but the links were made automatically when I tried this on Red Hat 5 and 6.

Running the script above does not make the new version of Java the default.  It simply registers that version of Java as a known version of java.  Run the following command to change the default.

You should see the following after entering the above command.

There are 3 programs which provide ‘java’.

Selection    Command

———————————————–

1           /usr/lib/jvm/jre-1.5.0-gcj/bin/java

*+ 2           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java

3           /usr/java/jre1.6.0_27/bin/java

Enter to keep the current selection[+], or type selection number:

I entered 3, and pressed the enter key, and the newly installed version of Java became the default.  You can run the update-alternatives command again to change the version back.

I assume that this works on other flavors of Linux as well, but I’ve never tried.  I have done this on both Red Hat Linux 5 and 6

SOURCE:

http://mikes-web-site.blogspot.com/2012/02/maintaining-multiple-java-versions-on.html