Hello,
Am trying to build an application which is very specific about pointing to a JDK by path instead of JRE.
Uninstalled all SuSE OEM JDK/JRE packages
Downloaded and installed SE JDK 5 from Sun
Added the new environmental variables for JAVA_HOME and PATH=$JAVA_HOME/bin:$PATH to /etc/profile (yes, I know that it’s preferable to add to /etc/profile.local instead)
I then checked the results and returned the proper results pointing to the new installed JDK (/usr/java/*[Sun java binary]) *
echo $JAVA_HOME
update-configurations --config java
which javac
but when I run the following command I still get a result pointing to an OEM JAVA (/usr/bin/java)
which java
/usr/bin/java
How do I fix this anomaly? I suspect this is still causing the build script to believe it’s pointing to a JRE.
Java, like everything else in SUSE, is an RPM so it is installed via the
RPM database and an RPM package. By default you have a system instance
of Java which you can find using the following command:
which java
Once you have those data you can reference it or you can add another
Java. As with any platform you can have as many installations of a JRE
or JDK as you’d like. Some of those can be installed via RPMs (and
would generally require ‘root’ access and would go in the filesystem
somewhere that ‘root’ can only write) and others can simply be extracted
somewhere for your individual user and used when you point to it. This
is all fairly standard across all platforms except the RPM part which
is, of course, common in Linux.
Good luck.
tsu2 wrote:
| Bump.
|
| Maybe asking this another way?
|
| Is there a reference that describes how Java is installed by Yast and
| what configuration files are modified in the process?
|
| TIA.
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Cool.
Thx for the clear explanation, but it still begs the question which relates to my original post…
If “which java” points to the system instance default, how would you re-point it to another instance?
I was surprised that by uninstalling the default system instances and installing a custom instance I was able to re-point the other queries including “which javac” but “which java” continued to point to a Java instance I had uninstalled.
Appreciate your patience…
BTW - I notice I incorrectly posted the query “update-alternatives --config java” above as “update-configurations --config java”
This is just basic system stuff. which <command> just searches the
current user’s $PATH variable for the command specified. If you want to
use a command that is already in the PATH but want to use a different
version in your own special location either modify your current path
(prepending the new location of your executable) or specify the absolute
path. For example:
export PATH=/path/to/my/new/directory:$PATH
or
/path/to/my/new/directory/java
Good luck.
tsu2 wrote:
| Cool.
| Thx for the clear explanation, but it still begs the question which
| relates to my original post…
|
| If “which java” points to the system instance default, how would you
| re-point it to another instance?
|
| I was surprised that by uninstalling the default system instances and
| installing a custom instance I was able to re-point the other queries
| including “which javac” but “which java” continued to point to a Java
| instance I had uninstalled.
|
| Appreciate your patience…
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Is interesting that I had added the new path as you described but that seems to be insufficient… The old path probably has to be explicitly removed as well. Awhile back I did determine which config file contained that path although the filename escapes me at the moment… It’s certainly not the “Profile” file where the modified entry is made.
You should NOT setup the JAVA_HOME variable yourself…
it gets set up for you. (along with some other java-related environment variables).
Note also that you can use update-alternatives to setup javac, etc. e.g
update-alternatives --config javac
and choose one. Thus, you could have javac pointing to, say,
v1.5, while having java pointing to, say, v1.6.
The whole idea is to allow you to have multiple versions of JRE and JDK installed,
and then to switch to the one that you want, when you want it.
But, aren’t those variables setup automatically <only> if you use the SuSE repository RPMs that install all versions of Java in the same folder?
Situation 1: If you install Java downloaded from the Sun website, Java gets installed into a different location, and I don’t see that version recognized automatically.
Situation 2: I just was able to install a third party application using the SuSE repository JDK5, but that required manually configuring the JAVA_HOME variable because installing the JDK5 also required installing the JRE, and the “Alternatives” file by default wouldn’t point to the JDK, only the JRE.
Unless I happened on a bug, the system seems fundamentally flawed at times getting everything to be configured automatically and properly using the alternatives options alone.
Unless I happened on a bug, the system seems fundamentally flawed at times getting everything to be configured automatically and properly using the alternatives options alone.
I’d recommend that you choose either
(1)all JREs/JDKs from the repo or
(2)all JREs/JDKs from external source.
As you’ve learned, trying some of each confuses the system for
resolving ‘JAVA_HOME’.*