For obsolete instructions for Fedora Core 5 (FC5) and Fedora Core 6 (FC6) version of this page look [ Here ].
The update for this page was inspired by email from David Nedrow (dnedrow at mac com). He sent me a short synopsis of how to do it with new Java 6 and Fedora 7, and I got new strengths to go through these steps again on my laptop. Thanks David...
If you want to upgrade JDK version but there is no compat package for it yet on JPackage site, read entire document without touching anything on your computer and then you will have known what to do.
As you can see from the Fedora and Java version numbers
I did not touch this page for a while. However, I got an email from someone
who used it, and he told me to stress:
Be sure to use the same version of the JDK compatability as the JDK you downloaded from SUN (Oracle). If you do not do it, things may not work, and you will not be able to uninstall the Java when update is needed. Also note that the jpackage17 is quite dated and there are probably newer versions, so you should use the newer ones. I do not want to say what to do with them, since I did not use them yet. When I do, I will create an updated page, since many things happened in the last 4 years, and some parts of this page may definitely be obsolete. Moreover, after SUN was acquired by Oracle, download server names have changed. Take it into consideration. The email also stressed that when you are using some hosting service, the JDK that you receive with the system may be quite dated, often 1.5. The latest stuff will not work with them (improvements(?!) in Generics, autoboxing, and Collections). You probably should install the latest Java SDK, since it is mostly backwards compatible, and will only warn you when you use deprecated methods or if you do not take advantage of Generics. You can always use -source and -target options on the javac compiler to get rid of some of the warnings.
What is the problem with F7 and JDK from Sun?
Fedora & Linux distribution comes with the GNU Java. This is a part of the popular GNU C compiler suite that also includes support for other programming languages, like Fortran. The GNU Java now supports most of the features of Sun Java 1.5 and in many cases can be augmented by additional open source packages to be almost functionally equivalent to the latest JDK from Sun. It has also some important advantages (e.g., option to produce native machine code) but it is by necessity behind with the features of the latest Java Development Kit from Sun. More information can be found at the GNU Compiler for the Java page at: http://gcc.gnu.org/java/. Recently Sun announced that it is legal to redistribute their Java Development Kit, however, it is unlikely that it will be a part of Fedora. The reason for this is that Sun Java Development Kit is not provided with the complete source code, while the Fedora Core Linux only provides packages that are open source. This may change in the future, but it is today
In most cases you will be fine with the Open Source, GNU Java. Most open source projects that need Java Development Kit do work with the GNU Java. But some do not... Especially those that push latest standards to the limits and require the latest features of the Java SDK from Sun. With the race to new standards for Java, you may need the Sun's Java SDK, but you also do not want to break the code that assumes that GNU Java is available on your machine. You will definitely need the Sun JDK if you use their latest and greatest IDEs or Enterprise type solutions. But YOU DO NOT WANT TO BRUTALLY DELETE/UNINSTALL the GNU Java or just put the Sun JDK into /opt and change the $JAVA_HOME and $CLASSPATH. Luckily there is a nice solution via alternatives package that comes with Fedora. We are even more lucky that there is a JPackage.org project and that Fedora supports it.
Make Sun JDK your default
Note: There are many approaches to installing Sun JDK under Linux. Some go through the route of building the RPM with paths and directories suitable for Fedora. What I describe here is a different approach in which the original Sun JDK RPM file is used, but it is brought into compliance with Fedora via creating symbolic links and the alternatives command through the JPackage.org RPM package.
Start from becoming a root by logging in as root or by sudo or simply by:
and get the latest JDK from Sun
Select the Java SE (Java Standard Edition), and then
Java SE (JDK) 6.
Choose the latest edition (at this writing it was JDK 6 Update 2,
and get the Linux RPM in self-extracting
file (DO NOT DOWNLOAD Linux self-extracting file!). You should
get a file like jdk-6u2-linux-i586-rpm.bin
that is about 65 MBytes in size. If it does not have
the rpm.bin at the end, you took the wrong one.
I would also (and strongly advise if you have disk to spare) to get the Java SE 6 Documentation (a jdk-6-doc.zip file) which is about 52 MBytes. There is also a Japanese version of docs but I do not speak this language. Once the documentation docs arrive, you can unpack them under your web server document tree, e.g., is you are using standard Apache on F7 do:
cd /var/www/html mkdir JDK-1.6 cd JDK-1.6 unzip ...jdk-6-doc.zip
and then view the docs under:
Of course, watch for Copyright. My advise is: make sure it cannot be
seen by people from outside your organization.
While you can view docs as files under FireFox, they have examples
will not run on a file: URL for security reasons).
While you are downloading this large file, please downloads the keys for the JPackage repository:
rpm --import http://jpackage.org/jpackage.asc
and install the JPackage repository information for the yum:
cd /etc/yum.repos.d wget http://www.jpackage.org/jpackage17.repo
If it did not work, maybe you do not have wget. You can check it with:
rpm -qi wget
and if you do not have it, install it with:
yum install wget
and try again to get the jpackage17.repo file.
The jpackage17.repo file comes with the jpackage-generic
repository enabled. However, I personally disabled the automatic
retrieval of updates and packages from the
repository by editing the /etc/yum.repos.d/jpackage17.repo
file and changing line(s) enabled=1 to the
enabled=0 . I do not want to
risk the situation when, due to some dependency, the new Java packages
will be installed on my machine without my knowledge during
updates that are run automatically at night. Moreover,
Fedora 7 default Java packages are already in the
Fedora repositories (i.e., were officially blessed
by Fedora team), and it is probably better to
try these repositories first rather than to go directly to the JPackage.org and
risk messing up some naming convention and/or dependencies.
At the same time, JPackage repository can be always enabled
in yum by adding the:
options on the command line.
Note... There are Fedora repositories on JPackage.org but there are no files in them from what I see. The jpackage17.repo file that you downloaded in the part
[jpackage-generic-nonfree] name=JPackage (non-free), generic mirrorlist=http://www.jpackage.org/jpackage_generic_nonfree_1.7.txt failovermethod=priority gpgcheck=1 gpgkey=http://www.jpackage.org/jpackage.asc enabled=0
is just wrong (at least on Sept 3, 2007 when I was trying). The problem is that the file: http://www.jpackage.org/jpackage_generic_nonfree_1.7.txt just does not exist. So rather than use a mirror list, I placed there specific URLs to the repositories. Therefore, edit the jpackage17.repo to read:
[jpackage-generic-nonfree] name=JPackage (non-free), generic baseurl= ftp://jpackage.hmdc.harvard.edu/JPackage/1.7/generic/non-free/ ftp://ftp.mirrorservice.org/sites/jpackage.org/1.7/generic/non-free/ http://sunsite.rediris.es/mirror/jpackage/1.7/generic/non-free/ ftp://ftp.pbone.net/pub/jpackage/1.7/generic failovermethod=priority # Check list on: http://www.jpackage.org/mirroring.php#mirrors # mirrorlist=http://www.jpackage.org/jpackage_generic_nonfree_1.7.txt gpgcheck=1 gpgkey=http://www.jpackage.org/jpackage.asc enabled=0
Of course, the other repositories in
jpackage17.repo file also
may need changing, but I did not go that far, since I am now only
installing JDK and I will worry later as also will you.
Since you will be dealing with RPMs, make also sure that you have packages to manipulate them:
rpm -qi rpm-build rpm -qi fedora-rpmdevtools
If you do not have them, install them:
yum install fedora-rpmdevtools yum install rpm-build
Check if you have packages for GNU Java compiler/libraries installed, since you most likely need to have some symmetry between GNU and Sun JDKs so the alternatives is not confused. But, frankly, I do not know the intrinsics of it, though it cannot hurt and disk space is cheap.
yum list available '*gcj*'
will list the available but not installed yet pieces of gcj (GNU Java compiler) and you can install these packages as:
yum install package1 package2...
yum install '*gcj*'
Please read the man page for alternatives:
When your Sun JDK Linux RPM self-extracting file finally arrives you need to execute it, since it is a shell script. It contains the license agreement and the compressed RPM package with Sun JDK. It will ask you if you agree to the long license. Say yes, then it will uncompress the RPM with JDK, and then it will install it together with bunch of other modules. To run it do:
chmod 755 jdk-6u2-linux-i586-rpm.bin ./jdk-6u2-linux-i586-rpm.bin
Unfortunately, the Sun RPM package puts files in different locations than the ones required by Fedora 7. After running the script you will see a new directory /usr/java/jdk1.6.0_02 with JDK files and directories and the new directory /opt/sun. In the directory where you ran the jdk-6u2-linux-i586-rpm.bin a bunch of *.rpm were created:
jdk-6u2-linux-i586.rpm sun-javadb-client-10.2.2-0.1.i386.rpm sun-javadb-common-10.2.2-0.1.i386.rpm sun-javadb-core-10.2.2-0.1.i386.rpm sun-javadb-demo-10.2.2-0.1.i386.rpm sun-javadb-docs-10.2.2-0.1.i386.rpm sun-javadb-javadoc-10.2.2-0.1.i386.rpm
You can look what files that are inside the RPMs by running rpm
rpm -q -l -p jdk-6u2-linux-i586.rpm rpm -q -l -p sun-javadb-client-10.2.2-0.1.i386.rpm rpm -q -l -p sun-javadb-common-10.2.2-0.1.i386.rpm ...
You can also use your browser (say FireFox) to look at the docs, but linking the doc location to a directory under web document tree. For example as:
cd /var/www/html/JDK-1.6 # or create it, if not created as described above ln -s /opt/sun/javadb javadb
and you will be able to point your browser to http://localhost/JDK-1.6/javadb and learn all the exciting details about Apache Derby for doing DB under Apache. Nice stuff, but not here... The actual RPMs are left in the directory where you ran the Sun's jdk-6u2-linux-i586.rpm.bin script, however, you do not need to process the RPMs, since the script already did it. You may, however, use the RPM packages later, if you want to install the JDK on another machine. Now, you are ready to install the SUN JDK compatibility RPM from the JPackage.org
yum --enablerepo=jpackage-generic-nonfree install java-1.6.0-sun-compat-1.6.0.02-1jpp
It should ask you for your Yes and announce:
This will create a bunch of links in the /etc/alternatives, /usr/share/man/man1, /usr/lib/jvm and others to the /usr/lib/jvm/java-1.6.0-sun link that points to the link that points to ... files in /usr/java/jdk1.6.0_02 where the Sun JDK distribution resides. To check which files were affected do:
rpm -q -l java-1.6.0-sun-compat
Check if the Sun JDK is really a default by doing:
If you get:
java version "1.5.0" gij (GNU libgcj) version 4.1.2 20070502 (Red Hat 4.1.2-12) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(or similar) then something did not work. If you get:
java version "1.6.0_02" Java(TM) SE Runtime Environment (build 1.6.0_02-b05) Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)
then the Sun JDK is your default. You can use alternatives to check (or change) the default JDK by:
alternatives --config java
It should show something like:
There are 2 programs which provide 'java'. Selection Command ----------------------------------------------- 1 /usr/lib/jvm/jre-1.4.2-gcj/bin/java *+ 2 /usr/lib/jvm/jre-1.5.0-sun/bin/java Enter to keep the current selection[+], or type selection number:
Hit [Enter] key if you want Sun JDK to be a default, or enter 1 if you want to change back to GNU Java. The JPackage compatibility should also make you a link for Java plug-in for Firefox browser. To make sure it did, do:
cd /usr/lib/mozilla/plugins ls -l
If you get:
lrwxrwxrwx 1 root root 77 Jun 17 20:47 libjavaplugin_oji.so -> /usr/lib/jvm/java-1.6.0-sun-1.6.0.02/jre/plugin/i386/ns7/libjavaplugin_oji.so
you should be fine. If you do not have it, make this link yourself (but then worry, since something is not right):
cd /usr/lib/mozilla/plugins ln -s /usr/lib/jvm/java-1.6.0-sun-1.6.0.02/jre/plugin/i386/ns7/libjavaplugin_oji.so \ libjavaplugin_oji.so
The Firefox should look for plug-ins in the /usr/lib/mozilla/plugins directory. If your Firefox still does not work with Java, put the link above also in the directory /usr/lib/firefox-126.96.36.199/plugins, or whatever is your particular version of Firefox that you can dig out from the script that runs it: /usr/bin/firefox or whatever is reported by:
There are different distros of Firefox, so you
may be special but for your own sake, use yum to
Updating your Sun JDK
If there is no compat rpm for the new JDK on the JPackage site, do not despair, and read further.
Now, there will be times, when you want to get rid of Sun JDK and its entries for alternatives. DO NOT TOUCH THESE LINKS WITH YOUR BARE HANDS. Use yum to uninstall the JPackage Java compatibility package first and then erase the Sun JDK with rpm:
yum erase java-1.6.0-sun-compat rpm -e jdk-1.6.0_02-fcs
Be bold... Do not worry... You can always reinstall it as described above. Of course, you can choose to use rpm command directly rather than yum to work with packages. But yum has a lot of advantages, since it will maintain the packages and upgrades and makes a lot of checks to see if things will not break. But sometimes they break. A popular situation is when you used rpm to install some package (or the package was installed with an install (older package is kept) rather than an update (older package is removed). In this case, yum gets confused with dependencies and complains, and it does not want to install a package. To see if this is a case, list all the installed rpm packages for some package name with a command:
rpm -qa | grep "^java" | sort
(Helpful suggestion from Bob Gustafson, Thanks!)
for example. If you see two versions of the same rpm, just erase the older (i.e., with the lower revision number) one. Use the
rpm -e full_package_name_with_version
(but skip the .rpm) and then
rpm -qa | grep "java-1.6.0-sun-compat" java-1.6.0-sun-compat-1.6.0.02-1jpp java-1.6.0-sun-compat-1.6.0.03-1jpp
remove the older package as:
yum erase java-1.6.0-sun-compat-1.6.0.02-1jpp
or, if still no go:
rpm -e java-1.6.0-sun-compat-1.6.0.02-1jpp
rpm -e --nopostun java-1.5.0-sun-1.5.0.09-1jpp
[ in general, if you see the error:
(Suggestions above from Bob Gustafson, Thanks!)
and check again if something is still left with:
rpm -qa | grep "^java" | sort
If you are still stuck, try deleting the Sun JDK first, e.g.:
rpm -e jdk-1.6.0_02-fcs
and then try to delete the compat RPMs again. This problem showed up in FC6 while upgrading JDK and I still do not know if this is an ugly bug or an interesting feature.
Updating your Sun JDK when the compat rpm package is not yet available from JPackage site
I upgraded from jdk-1.6.0_02-fcs to jdk-1.6.0_03-fcs on Oct 5, 2007, and there was no java-1.6.0-sun-compat-1.6.0.03-1jpp at that time. Of course, the stuff changes and can change enough that this simple patch to older compat rpm will not work. So... This is experimental at best.
First you need to erase your old compat rpm and Java SDK as described above. In this case the following did it:
yum erase java-1.6.0-sun-compat-1.6.0.02-1jpp yum erase jdk-1.6.0_02-fcs
Then you need to get a new JDK from Sun. In this case:
Then install the new JDK
chmod 755 jdk-6u3-linux-i586-rpm.bin ./jdk-6u2-linux-i586-rpm.bin
Then you have to downloads the old compat package but not the one you used to install the JDK but its source version. If you browse the JPackage site with the browser, http://www.jpackage.org/browser/browse.php?jppversion=1.7, they will be under non-free java-1.6.0-sun-compat at the end, then under the [S] link. In my case it was at: http://mirrors.dotsrc.org/jpackage/1.7/generic/non-free/SRPMS/java-1.6.0-sun-compat-1.6.0.02-1jpp.src.rpm . I also edited (or created, if you do not have it), the file: /root/.rpmmacros and placed there a line:
Then (as a root of course) I did
rpm -ihv java-1.6.0-sun-compat-1.6.0.02-1jpp.src.rpm
and the thing installed the following files:
/usr/src/redhat/SOURCES/java-1.6.0-sun-compat-register-java-fonts.xsl /usr/src/redhat/SOURCES/java-1.6.0-sun-compat-unregister-java-fonts.xsl /usr/src/redhat/SPECS/java-1.6.0-sun-compat.spec
You will need to edit the SPEC file (java-1.6.0-sun-compat.spec) before you can build the updated rpm package for the new JDK. In this case it is VERY EASY (I believe...). I changed the line:
%define buildver 02
to a line:
%define buildver 03
Then I ran the rpmbuild (which you have installed long time ago, didn't you? I talked about it at the top of this document).
cd /usr/src/redhat/SPECS rpmbuild -ba java-1.6.0-sun-compat.spec
This created a new, updated, compat rpm package in the directory /usr/src/redhat/RPMS/i586. So now what you need to do is:
cd /usr/src/redhat/RPMS/i586 rpm -ihv java-1.6.0-sun-compat-1.6.0.03-1jpp.i586.rpm
and you should be in this place in this document where you installed the compat package using yum and the JPackage repository
So... Where the heck is my JAVA_HOME?
JAVA_HOME=/usr/lib/jvm/java export JAVA_HOME
or if you are C-shellish:
setenv JAVA_HOME /usr/lib/jvm/java
Jan K. Labanowski
Computational Chemistry List, Ltd.
If you think that I erred, please let me know and I will be thankful and will correct... I promise... One more thing (a disclaimer...): If you believed in anything what I said, and you lost time and money, it is your fault... I am telling you again... I may have made a mistake, and I do not guarantee that anything will work as described...jkl at ccl . net