Ways to configure alternative installations of Oracle JDK on Ubuntu?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
When installing the latest Oracle JDK (8 or 9) on Ubuntu 16.04, I found several discussions:
https://askubuntu.com/questions/56104/how-can-i-install-sun-oracles-proprietary-java-jdk-6-7-8-or-jre/
https://askubuntu.com/questions/521145/how-to-install-oracle-java-on-ubuntu-14-04
https://askubuntu.com/questions/159575/how-do-i-make-java-default-to-a-manually-installed-jre-jdk
https://unix.stackexchange.com/a/418855/674
I summarize their ways into the following:
Some use
update-alternatives
. Among them, some use it forjava
,javac
andjavaws
(example), while some use it for more commands (
example, example, example, example). I am not sure which one gives the complete list of commands to applyupdate-alternatives
to.Some use
update-java-alternatives
(example, example, ), but some says it doesn't work for manual installation.Some use both
update-alternatives
andupdate-java-alternatives
(example)Some change several environment variables, and think that the previous two approaches are complicated unnecessarily (example, )
Some both use
update-alternatives
and change several environment variables: (example)Some install from ppa:webupd8team/java (example, example, example)
I wonder which way(s) is recommended?
Thanks.
ubuntu software-installation jdk
add a comment |Â
up vote
2
down vote
favorite
When installing the latest Oracle JDK (8 or 9) on Ubuntu 16.04, I found several discussions:
https://askubuntu.com/questions/56104/how-can-i-install-sun-oracles-proprietary-java-jdk-6-7-8-or-jre/
https://askubuntu.com/questions/521145/how-to-install-oracle-java-on-ubuntu-14-04
https://askubuntu.com/questions/159575/how-do-i-make-java-default-to-a-manually-installed-jre-jdk
https://unix.stackexchange.com/a/418855/674
I summarize their ways into the following:
Some use
update-alternatives
. Among them, some use it forjava
,javac
andjavaws
(example), while some use it for more commands (
example, example, example, example). I am not sure which one gives the complete list of commands to applyupdate-alternatives
to.Some use
update-java-alternatives
(example, example, ), but some says it doesn't work for manual installation.Some use both
update-alternatives
andupdate-java-alternatives
(example)Some change several environment variables, and think that the previous two approaches are complicated unnecessarily (example, )
Some both use
update-alternatives
and change several environment variables: (example)Some install from ppa:webupd8team/java (example, example, example)
I wonder which way(s) is recommended?
Thanks.
ubuntu software-installation jdk
Any way that works for you.
â TheWanderer
Jan 23 at 2:12
I guess Stephen doesn't think so unix.stackexchange.com/a/418855/674
â Tim
Jan 23 at 2:23
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
When installing the latest Oracle JDK (8 or 9) on Ubuntu 16.04, I found several discussions:
https://askubuntu.com/questions/56104/how-can-i-install-sun-oracles-proprietary-java-jdk-6-7-8-or-jre/
https://askubuntu.com/questions/521145/how-to-install-oracle-java-on-ubuntu-14-04
https://askubuntu.com/questions/159575/how-do-i-make-java-default-to-a-manually-installed-jre-jdk
https://unix.stackexchange.com/a/418855/674
I summarize their ways into the following:
Some use
update-alternatives
. Among them, some use it forjava
,javac
andjavaws
(example), while some use it for more commands (
example, example, example, example). I am not sure which one gives the complete list of commands to applyupdate-alternatives
to.Some use
update-java-alternatives
(example, example, ), but some says it doesn't work for manual installation.Some use both
update-alternatives
andupdate-java-alternatives
(example)Some change several environment variables, and think that the previous two approaches are complicated unnecessarily (example, )
Some both use
update-alternatives
and change several environment variables: (example)Some install from ppa:webupd8team/java (example, example, example)
I wonder which way(s) is recommended?
Thanks.
ubuntu software-installation jdk
When installing the latest Oracle JDK (8 or 9) on Ubuntu 16.04, I found several discussions:
https://askubuntu.com/questions/56104/how-can-i-install-sun-oracles-proprietary-java-jdk-6-7-8-or-jre/
https://askubuntu.com/questions/521145/how-to-install-oracle-java-on-ubuntu-14-04
https://askubuntu.com/questions/159575/how-do-i-make-java-default-to-a-manually-installed-jre-jdk
https://unix.stackexchange.com/a/418855/674
I summarize their ways into the following:
Some use
update-alternatives
. Among them, some use it forjava
,javac
andjavaws
(example), while some use it for more commands (
example, example, example, example). I am not sure which one gives the complete list of commands to applyupdate-alternatives
to.Some use
update-java-alternatives
(example, example, ), but some says it doesn't work for manual installation.Some use both
update-alternatives
andupdate-java-alternatives
(example)Some change several environment variables, and think that the previous two approaches are complicated unnecessarily (example, )
Some both use
update-alternatives
and change several environment variables: (example)Some install from ppa:webupd8team/java (example, example, example)
I wonder which way(s) is recommended?
Thanks.
ubuntu software-installation jdk
asked Jan 23 at 1:54
Tim
22.7k65224403
22.7k65224403
Any way that works for you.
â TheWanderer
Jan 23 at 2:12
I guess Stephen doesn't think so unix.stackexchange.com/a/418855/674
â Tim
Jan 23 at 2:23
add a comment |Â
Any way that works for you.
â TheWanderer
Jan 23 at 2:12
I guess Stephen doesn't think so unix.stackexchange.com/a/418855/674
â Tim
Jan 23 at 2:23
Any way that works for you.
â TheWanderer
Jan 23 at 2:12
Any way that works for you.
â TheWanderer
Jan 23 at 2:12
I guess Stephen doesn't think so unix.stackexchange.com/a/418855/674
â Tim
Jan 23 at 2:23
I guess Stephen doesn't think so unix.stackexchange.com/a/418855/674
â Tim
Jan 23 at 2:23
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
4
down vote
When I say that I recommend update-java-alternatives
for Java alternatives, IâÂÂm assuming that whatever Java providers are installed provide the necessary infrastructure. ThatâÂÂs the case for the OpenJDK packages available in Debian and its derivatives, but not necessarily for other JDK packages, and itâÂÂs unlikely to be the case for a manually-installed JDK. Oracle JDK packages created using java-package
do provide the necessary infrastructure. I donâÂÂt think itâÂÂs a sensible use of peopleâÂÂs time to set up the alternatives for all the Java commands manually: if you want to install the Oracle JRE or JDK, use java-package
.
The point of update-java-alternatives
is to allow a consistent setup of the default JRE/JDK tools. In theory, this could be done using update-alternatives
â --slave
relationships; however that doesnâÂÂt work generally for OpenJDK packages because you can have a subset of the available tools installed, which update-alternatives
doesnâÂÂt deal with. Hence the creation of update-java-alternatives
, which takes care of whatever tools are installed and doesnâÂÂt complain about anything else. For update-java-alternatives
to work though, JRE/JDK packages have to provide the necessary information, in a file in /usr/lib/jvm
(e.g. .java-1.8.0-openjdk-amd64.jinfo
). (update-alternatives
on RPM-based distributions does cope with this, apparently, but I havenâÂÂt looked into the details.)
Java itself has its own way of choosing among multiple installed JREs/JDKs, the JAVA_HOME
environment variable. update-java-alternatives
and JAVA_HOME
are really complementary: it should be possible to set both to point at different JREs/JDKs, depending on your requirements. update-java-alternatives
allows the system administrator to specify which JRE/JDK should be the default on a system (in fact, one might consider that it allows the package maintainers to specify which should be the default â itâÂÂs all supposed to work transparently for the administrators and users). JAVA_HOME
allows any user or startup script to specify which JRE/JDK should be used in a specific environment. Where things fall apart somewhat on Unix-style systems is with PATH
-handling, since PATH
canâÂÂt be set to dynamically use JAVA_HOME
to choose java
, javac
etc. (unlike on Windows); so you need to remember to re-set your PATH
when you change your JAVA_HOME
, if you want your default java
etc. to track your JAVA_HOME
setting (add $JAVA_HOME/bin
to the start of your PATH
).
The take-away from all this is similar to my answer to Can setting up environment variables replace using `update-alternatives`?: the system administrator should use update-java-alternatives
to define the default JRE/JDK for the system (or let the packages choose themselves), and users can use JAVA_HOME
to define the JRE/JDK for a specific environment.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
When I say that I recommend update-java-alternatives
for Java alternatives, IâÂÂm assuming that whatever Java providers are installed provide the necessary infrastructure. ThatâÂÂs the case for the OpenJDK packages available in Debian and its derivatives, but not necessarily for other JDK packages, and itâÂÂs unlikely to be the case for a manually-installed JDK. Oracle JDK packages created using java-package
do provide the necessary infrastructure. I donâÂÂt think itâÂÂs a sensible use of peopleâÂÂs time to set up the alternatives for all the Java commands manually: if you want to install the Oracle JRE or JDK, use java-package
.
The point of update-java-alternatives
is to allow a consistent setup of the default JRE/JDK tools. In theory, this could be done using update-alternatives
â --slave
relationships; however that doesnâÂÂt work generally for OpenJDK packages because you can have a subset of the available tools installed, which update-alternatives
doesnâÂÂt deal with. Hence the creation of update-java-alternatives
, which takes care of whatever tools are installed and doesnâÂÂt complain about anything else. For update-java-alternatives
to work though, JRE/JDK packages have to provide the necessary information, in a file in /usr/lib/jvm
(e.g. .java-1.8.0-openjdk-amd64.jinfo
). (update-alternatives
on RPM-based distributions does cope with this, apparently, but I havenâÂÂt looked into the details.)
Java itself has its own way of choosing among multiple installed JREs/JDKs, the JAVA_HOME
environment variable. update-java-alternatives
and JAVA_HOME
are really complementary: it should be possible to set both to point at different JREs/JDKs, depending on your requirements. update-java-alternatives
allows the system administrator to specify which JRE/JDK should be the default on a system (in fact, one might consider that it allows the package maintainers to specify which should be the default â itâÂÂs all supposed to work transparently for the administrators and users). JAVA_HOME
allows any user or startup script to specify which JRE/JDK should be used in a specific environment. Where things fall apart somewhat on Unix-style systems is with PATH
-handling, since PATH
canâÂÂt be set to dynamically use JAVA_HOME
to choose java
, javac
etc. (unlike on Windows); so you need to remember to re-set your PATH
when you change your JAVA_HOME
, if you want your default java
etc. to track your JAVA_HOME
setting (add $JAVA_HOME/bin
to the start of your PATH
).
The take-away from all this is similar to my answer to Can setting up environment variables replace using `update-alternatives`?: the system administrator should use update-java-alternatives
to define the default JRE/JDK for the system (or let the packages choose themselves), and users can use JAVA_HOME
to define the JRE/JDK for a specific environment.
add a comment |Â
up vote
4
down vote
When I say that I recommend update-java-alternatives
for Java alternatives, IâÂÂm assuming that whatever Java providers are installed provide the necessary infrastructure. ThatâÂÂs the case for the OpenJDK packages available in Debian and its derivatives, but not necessarily for other JDK packages, and itâÂÂs unlikely to be the case for a manually-installed JDK. Oracle JDK packages created using java-package
do provide the necessary infrastructure. I donâÂÂt think itâÂÂs a sensible use of peopleâÂÂs time to set up the alternatives for all the Java commands manually: if you want to install the Oracle JRE or JDK, use java-package
.
The point of update-java-alternatives
is to allow a consistent setup of the default JRE/JDK tools. In theory, this could be done using update-alternatives
â --slave
relationships; however that doesnâÂÂt work generally for OpenJDK packages because you can have a subset of the available tools installed, which update-alternatives
doesnâÂÂt deal with. Hence the creation of update-java-alternatives
, which takes care of whatever tools are installed and doesnâÂÂt complain about anything else. For update-java-alternatives
to work though, JRE/JDK packages have to provide the necessary information, in a file in /usr/lib/jvm
(e.g. .java-1.8.0-openjdk-amd64.jinfo
). (update-alternatives
on RPM-based distributions does cope with this, apparently, but I havenâÂÂt looked into the details.)
Java itself has its own way of choosing among multiple installed JREs/JDKs, the JAVA_HOME
environment variable. update-java-alternatives
and JAVA_HOME
are really complementary: it should be possible to set both to point at different JREs/JDKs, depending on your requirements. update-java-alternatives
allows the system administrator to specify which JRE/JDK should be the default on a system (in fact, one might consider that it allows the package maintainers to specify which should be the default â itâÂÂs all supposed to work transparently for the administrators and users). JAVA_HOME
allows any user or startup script to specify which JRE/JDK should be used in a specific environment. Where things fall apart somewhat on Unix-style systems is with PATH
-handling, since PATH
canâÂÂt be set to dynamically use JAVA_HOME
to choose java
, javac
etc. (unlike on Windows); so you need to remember to re-set your PATH
when you change your JAVA_HOME
, if you want your default java
etc. to track your JAVA_HOME
setting (add $JAVA_HOME/bin
to the start of your PATH
).
The take-away from all this is similar to my answer to Can setting up environment variables replace using `update-alternatives`?: the system administrator should use update-java-alternatives
to define the default JRE/JDK for the system (or let the packages choose themselves), and users can use JAVA_HOME
to define the JRE/JDK for a specific environment.
add a comment |Â
up vote
4
down vote
up vote
4
down vote
When I say that I recommend update-java-alternatives
for Java alternatives, IâÂÂm assuming that whatever Java providers are installed provide the necessary infrastructure. ThatâÂÂs the case for the OpenJDK packages available in Debian and its derivatives, but not necessarily for other JDK packages, and itâÂÂs unlikely to be the case for a manually-installed JDK. Oracle JDK packages created using java-package
do provide the necessary infrastructure. I donâÂÂt think itâÂÂs a sensible use of peopleâÂÂs time to set up the alternatives for all the Java commands manually: if you want to install the Oracle JRE or JDK, use java-package
.
The point of update-java-alternatives
is to allow a consistent setup of the default JRE/JDK tools. In theory, this could be done using update-alternatives
â --slave
relationships; however that doesnâÂÂt work generally for OpenJDK packages because you can have a subset of the available tools installed, which update-alternatives
doesnâÂÂt deal with. Hence the creation of update-java-alternatives
, which takes care of whatever tools are installed and doesnâÂÂt complain about anything else. For update-java-alternatives
to work though, JRE/JDK packages have to provide the necessary information, in a file in /usr/lib/jvm
(e.g. .java-1.8.0-openjdk-amd64.jinfo
). (update-alternatives
on RPM-based distributions does cope with this, apparently, but I havenâÂÂt looked into the details.)
Java itself has its own way of choosing among multiple installed JREs/JDKs, the JAVA_HOME
environment variable. update-java-alternatives
and JAVA_HOME
are really complementary: it should be possible to set both to point at different JREs/JDKs, depending on your requirements. update-java-alternatives
allows the system administrator to specify which JRE/JDK should be the default on a system (in fact, one might consider that it allows the package maintainers to specify which should be the default â itâÂÂs all supposed to work transparently for the administrators and users). JAVA_HOME
allows any user or startup script to specify which JRE/JDK should be used in a specific environment. Where things fall apart somewhat on Unix-style systems is with PATH
-handling, since PATH
canâÂÂt be set to dynamically use JAVA_HOME
to choose java
, javac
etc. (unlike on Windows); so you need to remember to re-set your PATH
when you change your JAVA_HOME
, if you want your default java
etc. to track your JAVA_HOME
setting (add $JAVA_HOME/bin
to the start of your PATH
).
The take-away from all this is similar to my answer to Can setting up environment variables replace using `update-alternatives`?: the system administrator should use update-java-alternatives
to define the default JRE/JDK for the system (or let the packages choose themselves), and users can use JAVA_HOME
to define the JRE/JDK for a specific environment.
When I say that I recommend update-java-alternatives
for Java alternatives, IâÂÂm assuming that whatever Java providers are installed provide the necessary infrastructure. ThatâÂÂs the case for the OpenJDK packages available in Debian and its derivatives, but not necessarily for other JDK packages, and itâÂÂs unlikely to be the case for a manually-installed JDK. Oracle JDK packages created using java-package
do provide the necessary infrastructure. I donâÂÂt think itâÂÂs a sensible use of peopleâÂÂs time to set up the alternatives for all the Java commands manually: if you want to install the Oracle JRE or JDK, use java-package
.
The point of update-java-alternatives
is to allow a consistent setup of the default JRE/JDK tools. In theory, this could be done using update-alternatives
â --slave
relationships; however that doesnâÂÂt work generally for OpenJDK packages because you can have a subset of the available tools installed, which update-alternatives
doesnâÂÂt deal with. Hence the creation of update-java-alternatives
, which takes care of whatever tools are installed and doesnâÂÂt complain about anything else. For update-java-alternatives
to work though, JRE/JDK packages have to provide the necessary information, in a file in /usr/lib/jvm
(e.g. .java-1.8.0-openjdk-amd64.jinfo
). (update-alternatives
on RPM-based distributions does cope with this, apparently, but I havenâÂÂt looked into the details.)
Java itself has its own way of choosing among multiple installed JREs/JDKs, the JAVA_HOME
environment variable. update-java-alternatives
and JAVA_HOME
are really complementary: it should be possible to set both to point at different JREs/JDKs, depending on your requirements. update-java-alternatives
allows the system administrator to specify which JRE/JDK should be the default on a system (in fact, one might consider that it allows the package maintainers to specify which should be the default â itâÂÂs all supposed to work transparently for the administrators and users). JAVA_HOME
allows any user or startup script to specify which JRE/JDK should be used in a specific environment. Where things fall apart somewhat on Unix-style systems is with PATH
-handling, since PATH
canâÂÂt be set to dynamically use JAVA_HOME
to choose java
, javac
etc. (unlike on Windows); so you need to remember to re-set your PATH
when you change your JAVA_HOME
, if you want your default java
etc. to track your JAVA_HOME
setting (add $JAVA_HOME/bin
to the start of your PATH
).
The take-away from all this is similar to my answer to Can setting up environment variables replace using `update-alternatives`?: the system administrator should use update-java-alternatives
to define the default JRE/JDK for the system (or let the packages choose themselves), and users can use JAVA_HOME
to define the JRE/JDK for a specific environment.
answered Jan 23 at 8:10
Stephen Kitt
142k22308371
142k22308371
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f418985%2fways-to-configure-alternative-installations-of-oracle-jdk-on-ubuntu%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Any way that works for you.
â TheWanderer
Jan 23 at 2:12
I guess Stephen doesn't think so unix.stackexchange.com/a/418855/674
â Tim
Jan 23 at 2:23