17 thoughts on - Java 1.6 And 1.7 On CentOS

• Asma rabe writes:

  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.

• 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-on-fedora-CentOS-red-hat-rhel/
  http://www.if-not-true-then-false.com/2014/install-oracle-java-8-on-fedora-CentOS-rhel/

• 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

  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.

• 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.

  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…

• 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.

• 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.

• 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.

• 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.

  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.

• But do you really need _two_ symlinks to get a default in your PATH?

  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?

• 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.

  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.

• What is formally correct about putting executables in some obscure place under /var?

  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.

• 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

  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.

• 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?

  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.

• 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.