Hi ,
I have java 1.7 installed on CentOS machine. when i tried to run java program i got an error and found that i should run it using java 1.6.
Is the best solution to install Java 1.6 and have both java 1.6 and java 1.7 at same time? or is there a better solution.
If i should install both java 1.6 and 1.7 , how to do that ?
Thank you very much.
Best Regards,
Asma
Asma rabe asma.rabe@gmail.com writes:
If i should install both java 1.6 and 1.7 , how to do that ?
I don't know whether you *should* do it, not knowing much about your setup, but assuming CentOS 7, I think you can install both the java-1.6.0-openjdk and java-1.7.0-openjdk packages.
On 2014-08-19, Carson Chittom carson@wistly.net wrote:
Asma rabe asma.rabe@gmail.com writes:
If i should install both java 1.6 and 1.7 , how to do that ?
I don't know whether you *should* do it, not knowing much about your setup, but assuming CentOS 7, I think you can install both the java-1.6.0-openjdk and java-1.7.0-openjdk packages.
I can confirm that. I have both installed. You can configure the default using the 'alternatives' system.
On 8/19/2014 5:16 AM, Liam O'Toole wrote:
On 2014-08-19, Carson Chittomcarson@wistly.net wrote:
Asma rabeasma.rabe@gmail.com writes:
If i should install both java 1.6 and 1.7 , how to do that ?
I don't know whether you*should* do it, not knowing much about your setup, but assuming CentOS 7, I think you can install both the java-1.6.0-openjdk and java-1.7.0-openjdk packages.
I can confirm that. I have both installed. You can configure the default using the 'alternatives' system.
is it just me, or does anyone else think that 'alternatives' system is completely bogus?
what if I have one user that wants JDK6 and another that needs JDK7 ?
On Tue, Aug 19, 2014 at 1:33 PM, John R Pierce pierce@hogranch.com wrote:
If i should install both java 1.6 and 1.7 , how to do that ?
I don't know whether you*should* do it, not knowing much about your setup, but assuming CentOS 7, I think you can install both the java-1.6.0-openjdk and java-1.7.0-openjdk packages.
I can confirm that. I have both installed. You can configure the default using the 'alternatives' system.
is it just me, or does anyone else think that 'alternatives' system is completely bogus?
what if I have one user that wants JDK6 and another that needs JDK7 ?
Yes, I think pretty much everything in recent Linux distributions is aimed at making it more single-user and PC-like instead of a unix server. Following Apple's lead, I guess. But even a single user may need to run applications with differing requirements. Fortunately you can still set JAVA_HOME and give a full path to either executable - you just have to follow the weird symlinks or list the paths from the rpm to figure out where they really put things.
On 8/19/2014 12:08 PM, Les Mikesell wrote:
Yes, I think pretty much everything in recent Linux distributions is aimed at making it more single-user and PC-like instead of a unix server. Following Apple's lead, I guess. But even a single user may need to run applications with differing requirements. Fortunately you can still set JAVA_HOME and give a full path to either executable - you just have to follow the weird symlinks or list the paths from the rpm to figure out where they really put things.
setting JAVA_HOME generally isn't required for running java at the shell, just putting the right java bin directory first in the path is sufficient...
when you invoke java, it sets JAVA_HOME itself if its not already set.
and, WOW, what a tangled web of symlinks.
export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el7_0.x86_64/jre export PATH=$JAVA_HOME/bin:$PATH
is the REAL java directory... but that will change with a minor update. yuck!!!
On 2014-08-19, John R Pierce pierce@hogranch.com wrote:
On 8/19/2014 12:08 PM, Les Mikesell wrote:
Yes, I think pretty much everything in recent Linux distributions is aimed at making it more single-user and PC-like instead of a unix server. Following Apple's lead, I guess. But even a single user may need to run applications with differing requirements. Fortunately you can still set JAVA_HOME and give a full path to either executable - you just have to follow the weird symlinks or list the paths from the rpm to figure out where they really put things.
setting JAVA_HOME generally isn't required for running java at the shell, just putting the right java bin directory first in the path is sufficient...
when you invoke java, it sets JAVA_HOME itself if its not already set.
and, WOW, what a tangled web of symlinks.
export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el7_0.x86_64/jre export PATH=$JAVA_HOME/bin:$PATH
is the REAL java directory... but that will change with a minor update. yuck!!!
Just set JAVA_HOME to /usr/lib/jvm/jre-1.7.0-openjdk, or to /usr/lib/jvm/jre-1.7.0 if you don't care about the implementation. Those will survive updates.
On Tue, Aug 19, 2014 at 2:25 PM, John R Pierce pierce@hogranch.com wrote:
On 8/19/2014 12:08 PM, Les Mikesell wrote:
Yes, I think pretty much everything in recent Linux distributions is aimed at making it more single-user and PC-like instead of a unix server. Following Apple's lead, I guess. But even a single user may need to run applications with differing requirements. Fortunately you can still set JAVA_HOME and give a full path to either executable - you just have to follow the weird symlinks or list the paths from the rpm to figure out where they really put things.
setting JAVA_HOME generally isn't required for running java at the shell, just putting the right java bin directory first in the path is sufficient...
when you invoke java, it sets JAVA_HOME itself if its not already set.
and, WOW, what a tangled web of symlinks.
export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el7_0.x86_64/jre export PATH=$JAVA_HOME/bin:$PATH
is the REAL java directory... but that will change with a minor update. yuck!!!
You usually end up with a symlink like /usr/java/latest pointing to a versioned directory even if you install your own from Oracle, but with just half of the mess and you know where the real thing is.
If you just execute java and it just runs a single app you can get away without setting JAVA_HOME. But if you do something like executing ant (which starts as a shell script that tries to find java for you, or some more complex thing that is going to need javac and friends) you are better off setting it to where you want it.
On 19/08/14 20:33, John R Pierce wrote:
On 8/19/2014 5:16 AM, Liam O'Toole wrote:
On 2014-08-19, Carson Chittomcarson@wistly.net wrote:
Asma rabeasma.rabe@gmail.com writes:
If i should install both java 1.6 and 1.7 , how to do that ?
I don't know whether you*should* do it, not knowing much about your setup, but assuming CentOS 7, I think you can install both the java-1.6.0-openjdk and java-1.7.0-openjdk packages.
I can confirm that. I have both installed. You can configure the default using the 'alternatives' system.
is it just me, or does anyone else think that 'alternatives' system is completely bogus?
I've always seen it as designed mostly for system services for which there are several common implementations - like the SMTP server or the printing system. Where I think it makes sense.
It may also be useful to be able to set up a system-wide default for user applications "with alternatives", but I suppose a user override ought to be possible in that case.
what if I have one user that wants JDK6 and another that needs JDK7 ?
I guess the "preferred applications" system in the desktop is in a way meant for such cases, but this of course comes across as incomplete, too.
- Toralf
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
On Wed, Aug 20, 2014 at 8:25 AM, Toralf Lund toralf.lund@pgs.com wrote:
On 19/08/14 20:33, John R Pierce wrote:
> If i should install both java 1.6 and 1.7 , how to do that ?
I don't know whether you*should* do it, not knowing much about your setup, but assuming CentOS 7, I think you can install both the java-1.6.0-openjdk and java-1.7.0-openjdk packages.
I can confirm that. I have both installed. You can configure the default using the 'alternatives' system.
is it just me, or does anyone else think that 'alternatives' system is completely bogus?
I've always seen it as designed mostly for system services for which there are several common implementations - like the SMTP server or the printing system. Where I think it makes sense.
But do you really need _two_ symlinks to get a default in your PATH?
It may also be useful to be able to set up a system-wide default for user applications "with alternatives", but I suppose a user override ought to be possible in that case.
what if I have one user that wants JDK6 and another that needs JDK7 ?
I guess the "preferred applications" system in the desktop is in a way meant for such cases, but this of course comes across as incomplete, too.
The concept used for 'software collections' is a more realistic approach - but instead of hiding where things land and needing a tool to set up use, why not just tell people what to add to their own PATH and LD_LIBRARY path to get the version you want. That's almost certainly what the developers of every package where they need to have test versions does. So why treat the users like they would be too dumb for that?
On 20/08/14 15:43, Les Mikesell wrote:
On Wed, Aug 20, 2014 at 8:25 AM, Toralf Lund toralf.lund@pgs.com wrote:
On 19/08/14 20:33, John R Pierce wrote:
>> If i should install both java 1.6 and 1.7 , how to do that ? I don't know whether you*should* do it, not knowing much about your setup, but assuming CentOS 7, I think you can install both the java-1.6.0-openjdk and java-1.7.0-openjdk packages.
I can confirm that. I have both installed. You can configure the default using the 'alternatives' system.
is it just me, or does anyone else think that 'alternatives' system is completely bogus?
I've always seen it as designed mostly for system services for which there are several common implementations - like the SMTP server or the printing system. Where I think it makes sense.
But do you really need _two_ symlinks to get a default in your PATH?
I think the argument is that "configuration" commands shouldn't change bin directories. Which is right in a way, but maybe this is one of the cases where practicality should have been chosen over formal correctness.
It may also be useful to be able to set up a system-wide default for user applications "with alternatives", but I suppose a user override ought to be possible in that case.
what if I have one user that wants JDK6 and another that needs JDK7 ?
I guess the "preferred applications" system in the desktop is in a way meant for such cases, but this of course comes across as incomplete, too.
The concept used for 'software collections' is a more realistic approach - but instead of hiding where things land and needing a tool to set up use, why not just tell people what to add to their own PATH and LD_LIBRARY path to get the version you want. That's almost certainly what the developers of every package where they need to have test versions does. So why treat the users like they would be too dumb for that?
That's a point.
You could also easily develop "config" tools that would make that job easier for "dumb" users - this might be more productive than maintaining different solution that essentially have the same effect.
- Toralf
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
On Wed, Aug 20, 2014 at 9:02 AM, Toralf Lund toralf.lund@pgs.com wrote:
I can confirm that. I have both installed. You can configure the default using the 'alternatives' system.
is it just me, or does anyone else think that 'alternatives' system is completely bogus?
I've always seen it as designed mostly for system services for which there are several common implementations - like the SMTP server or the printing system. Where I think it makes sense.
But do you really need _two_ symlinks to get a default in your PATH?
I think the argument is that "configuration" commands shouldn't change bin directories. Which is right in a way, but maybe this is one of the cases where practicality should have been chosen over formal correctness.
What is formally correct about putting executables in some obscure place under /var?
It may also be useful to be able to set up a system-wide default for user applications "with alternatives", but I suppose a user override ought to be possible in that case.
what if I have one user that wants JDK6 and another that needs JDK7 ?
I guess the "preferred applications" system in the desktop is in a way meant for such cases, but this of course comes across as incomplete, too.
The concept used for 'software collections' is a more realistic approach - but instead of hiding where things land and needing a tool to set up use, why not just tell people what to add to their own PATH and LD_LIBRARY path to get the version you want. That's almost certainly what the developers of every package where they need to have test versions does. So why treat the users like they would be too dumb for that?
That's a point.
You could also easily develop "config" tools that would make that job easier for "dumb" users - this might be more productive than maintaining different solution that essentially have the same effect.
Or you could just not pretend that users are dumb for choosing your product. And not hide the purpose, content, and functionality of PATH and LD_LIBRARY_PATH, things that every developer who needs to have a 'stable, trusted' version of an application along with today's build is going to understand and utilize. So it's probably not those developers that came up with the weird alternatives scheme - or at least decided to use it for applications that really need concurrent alternatives, not a site-wide default.
On 20/08/14 16:45, Les Mikesell wrote:
On Wed, Aug 20, 2014 at 9:02 AM, Toralf Lund toralf.lund@pgs.com wrote:
I can confirm that. I have both installed. You can configure the default using the 'alternatives' system.
is it just me, or does anyone else think that 'alternatives' system is completely bogus?
I've always seen it as designed mostly for system services for which there are several common implementations - like the SMTP server or the printing system. Where I think it makes sense.
But do you really need _two_ symlinks to get a default in your PATH?
I think the argument is that "configuration" commands shouldn't change bin directories. Which is right in a way, but maybe this is one of the cases where practicality should have been chosen over formal correctness.
What is formally correct about putting executables in some obscure place under /var?
I'm not quite sure what you mean by that. For the alternatives setup I have links on /usr/bin or whatever pointing to other links on /etc/alternatives, which in turn point to the real files - where direct links from /usr/bin would of course be simpler. Perhaps you were talking about something else, or are the locations different on CentOS 7 (I'm using version 6.)
What I was referring to is that I believe it's considered as incorrect to put "dynamic" data on /usr these days. I'm not sure there is a separate specification saying so, or if it's just taken to be implied by the FHS (http://www.pathname.com/fhs/pub/fhs-2.3.html).
- T
It may also be useful to be able to set up a system-wide default for user applications "with alternatives", but I suppose a user override ought to be possible in that case.
what if I have one user that wants JDK6 and another that needs JDK7 ?
I guess the "preferred applications" system in the desktop is in a way meant for such cases, but this of course comes across as incomplete, too.
The concept used for 'software collections' is a more realistic approach - but instead of hiding where things land and needing a tool to set up use, why not just tell people what to add to their own PATH and LD_LIBRARY path to get the version you want. That's almost certainly what the developers of every package where they need to have test versions does. So why treat the users like they would be too dumb for that?
That's a point.
You could also easily develop "config" tools that would make that job easier for "dumb" users - this might be more productive than maintaining different solution that essentially have the same effect.
Or you could just not pretend that users are dumb for choosing your product. And not hide the purpose, content, and functionality of PATH and LD_LIBRARY_PATH, things that every developer who needs to have a 'stable, trusted' version of an application along with today's build is going to understand and utilize. So it's probably not those developers that came up with the weird alternatives scheme - or at least decided to use it for applications that really need concurrent alternatives, not a site-wide default.
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
On Thu, Aug 21, 2014 at 4:15 AM, Toralf Lund toralf.lund@pgs.com wrote:
What is formally correct about putting executables in some obscure place under /var?
I'm not quite sure what you mean by that. For the alternatives setup I have links on /usr/bin or whatever pointing to other links on /etc/alternatives, which in turn point to the real files - where direct links from /usr/bin would of course be simpler. Perhaps you were talking about something else, or are the locations different on CentOS 7 (I'm using version 6.)
So what do you have to execute when you want to run a jvm that is not the current system default in alternatives? And why does anyone think that is a formally correct place?
What I was referring to is that I believe it's considered as incorrect to put "dynamic" data on /usr these days. I'm not sure there is a separate specification saying so, or if it's just taken to be implied by the FHS (http://www.pathname.com/fhs/pub/fhs-2.3.html).
Committee decisions are normally bad enough, but changing them all the time makes them even worse - but I suppose they have to do something to justify their existence. /usr had a well defined role from the beginning of unix - and that was to not hold anything needed for booting. /sbin and /usr/sbin are just weird, as though users don't need to run common commands like ifconfig. /var for the java executables?? /opt might have made sense.
On Fri, Aug 22, 2014 at 9:55 AM, Les Mikesell lesmikesell@gmail.com wrote:
/var for the java executables?? /opt might have made sense.
Oops, I guess it is actually under /usr/lib/jvm which isn't quite as bad, but still not the first place you'd expect for an executables like java, javac, jar, jconsole, etc. to live.
On 08/19/2014 07:00 AM, Carson Chittom wrote:
Asma rabe asma.rabe@gmail.com writes:
If i should install both java 1.6 and 1.7 , how to do that ?
I don't know whether you *should* do it, not knowing much about your setup, but assuming CentOS 7, I think you can install both the java-1.6.0-openjdk and java-1.7.0-openjdk packages.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
If you're interested in Oracle's Java, here are tutorials to install versions 7 and 8:
http://www.if-not-true-then-false.com/2010/install-sun-oracle-java-jdk-jre-7... http://www.if-not-true-then-false.com/2014/install-oracle-java-8-on-fedora-c...
On 19/08/14 14:48, Chris Pemberton wrote:
On 08/19/2014 07:00 AM, Carson Chittom wrote:
Asma rabe asma.rabe@gmail.com writes:
If i should install both java 1.6 and 1.7 , how to do that ?
I don't know whether you *should* do it, not knowing much about your setup, but assuming CentOS 7, I think you can install both the java-1.6.0-openjdk and java-1.7.0-openjdk packages.
I haven't tried that on CentOS 7, but it certainly works on CentOS 6. Java 1.7 is probably there already, and 1.6 can be installed via
yum install java-1.6.0-openjdk
The trick here is that java 1.7 and java 1.6 are provided by what's technically two different packages, as opposed to different versions of one package.
alternatives --config java
Let's you select which of the installed java releases will be started by the "java" program.
Note that this is not necessarily the same as what's run by the java plugin. For that, you may want to di
alternatives --config jre_openjdk
instead.
- T
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
If you're interested in Oracle's Java, here are tutorials to install versions 7 and 8:
http://www.if-not-true-then-false.com/2010/install-sun-oracle-java-jdk-jre-7... http://www.if-not-true-then-false.com/2014/install-oracle-java-8-on-fedora-c... _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.
On Tue, Aug 19, 2014 at 6:06 AM, Asma rabe asma.rabe@gmail.com wrote:
I have java 1.7 installed on CentOS machine. when i tried to run java program i got an error and found that i should run it using java 1.6.
Is the best solution to install Java 1.6 and have both java 1.6 and java 1.7 at same time? or is there a better solution.
Java is packaged with different names for the 1.6 and 1.7 openjdk versions. You can find all the relevant packages with 'yum search java' or 'yum search openjdk'. The corresponding -devel packages have the compilers in case you need more than the runtime. If all of your java applications will run on 1.6 you can simply remove any 1.7 packages you have and make sure 1.6 is installed.
If i should install both java 1.6 and 1.7 , how to do that ?
You can install both with yum like any other packages. However, they both install in odd places and use a set of double symlinks managed by the alternatives package to put one or the other in your PATH as the default version. Obviously you can only have one default, but you may in fact need to run different applications that require different versions simultaneously - or different users on the same system may have different requirements. If you need to run a non-default version, you should export JAVA_HOME=/path/to/that/installation (which will be something obvious under ./usr/lib/jvm, but be sure you understand the symlinks) and execute the full path to java in the bin subdirectory of that location. And thank RedHat for making it so simple...
-
Asma rabe -
Carson Chittom -
Chris Pemberton -
John R Pierce -
Les Mikesell -
Liam O'Toole -
Toralf Lund