Linux Step By Steps

IBM Java on Linux, Java 2 Technology Edition

Prepared by Pascal Chong on 25 January 2004

Table of Contents
Revision History
Getting the IBM Java 2 SDK
Tested Platforms
System Requirements
Uninstalling Existing Versions
Installing the IBM Developer Kit
Setting up the Environment
Testing Your Installation
Troubleshooting Your Installation
Where Do We Go From Here?
Appendix A. Segmentation Faults On gcc 3.x Systems
Appendix B. Installing the Java Plug-In
Appendix C. Classpath Considerations for version 1.4.x and 1.3.1

Revision History

Table 1. Revision History Table

23 January 2004 Covers IBM Java 2 version 1.4.1
19 February 2003 Initial Release


I do not work for IBM, and this document should not be treated as authoritative. Whatever is expressed here are my views and experiences with the IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition. The steps outlined here worked for me, they may not work for you, so be careful when you use this document, and be aware that you are using this at your own risk !

For proper support, you should read IBM's documents that come with the download, or post your questions on the IBM newsgroup. I believe you can also pay for it under a support contract with IBM.

Getting the IBM Java 2 SDK

The IBM Developer Kit for Linux can be downloaded from this location: The latest versions are also listed on that page, for all available platforms. At the time of this writing, the latest versions are :

Table 2. Current Versions of the IBM Developer Kit for Linux

version 1.4.1 Service Release (SR) 1 IBM SDK for 32-bit xSeries (Intel compatible)
version 1.3.1 Service Release (SR) 6 IBM SDK for 32-bit xSeries (Intel compatible)

I am not sure if the Developer Kit works for 64-bit platforms, such as the new AMD Opteron processors. If anyone has tried, please let me know.

There are 2 downloadable packages for Linux : RPMs and tarballs. There is really very little difference between the two packages -- the rpm package does not modify any configuration files, and it unpacks into a single directory, instead of putting files in all kinds of different directories.

There are several different packages available for download, once you register and are directed to the download page:

Table 3. Downloadable Packages for Java 2 v 1.4.1

IBMJava2-SDK-1.4.1-1.0.i386.rpm This is the Java 2 Software Development Kit. You will need this if you are compiling your own Java programs, or running JSPs.
IBMJava2-JRE-1.4.1-1.0.i386.rpm This is the Java 2 Runtime Environment. If you don't need to compile any Java programs, you only need this. If you are looking for a Java Plug-In for your browser, you'll need something different. See Appendix B.
IBMJava2-JAVACOMM-1.4.1-1.0.i386.rpm This is an optional package for the Java 2 SDK. If your Java programs need to interface with external devices through the serial port, you'll need this package.
readmefirst.lnxia32.txt Late breaking information about the Developer and Runtime Kits. This contains useful information about a link where you can get diagnostic information in case your installation does not work as expected.
runtimeguide.lnxia32.en.html User guide for the JRE (Java Runtime Environment)
sdkguide.lnxia32.html User guide for the Java 2 SDK. Read this first before compiling and running your Java programs! A lot of useful information here for the Java developer.
securityguide.lnx.html Developing applications that make use of cryptography, SSL ? You will want to read this first. There are differences between the security facilities provided by IBM and Sun, and you will need to know about it.

There are also tarballs available for download, but I shall not be covering the tar packages in this document.

Tested Platforms

I have successfully run IBM's Java on Fedora Core 1, Red Hat Linux 9/8 and Probatus SpectraLinux 1.2.

There are some special considerations for Fedora Core 1 and Red Hat Linux 9, and other Linuxes that use the Native Posix Thread Library. These are addressed in Appendix A.

System Requirements

If you are running the more recent versions of the IBM Java Development Kit (that is, version 1.3.1, 1.4.0 or 1.4.1), my recommendation is that you should be using kernel 2.4.18 or better. This is because of certain problems and issues in earlier kernel versions. Though unrelated to Java itself, some of the earlier kernel bugs can cause system lock-ups.

If you are using a multi-processor system, and you are encountering segmentation faults or other mysterious errors, you might want to turn off the Just-In-Time (JIT) compiler. By some accounts on the IBM newsgroup, this solves the problem.

Uninstalling Existing Versions

If you installed an earlier version of the IBM Java Development Kit, you will need to remove it first, before installing the new version. There is no "refresh" or "upgrade" option here.

# rpm -e IBMJava2-SDK 
# rpm -e IBMJava2-JAAS
# rpm -e IBMJava2-JAVACOMM

If you installed any additional libraries or jar files in your $JAVA_HOME/lib directory, the uninstall will not delete the directory structure. You will have to manually delete the directories yourself.

Installing the IBM Developer Kit

This is a relatively simple process. Go to the directory where you downloaded the RPMs and, as root, execute the following commands :

# rpm -ivh IBMJava2-SDK* 
# rpm -ivh IBMJava2-JAAS*
# rpm -ivh IBMJava2-JAVACOMM*

This will install the base Java SDK into /opt/IBMJava2-131/ along with the optional components.

JAAS is the Java Authentication and Authorization Service which enables services to authenticate and enforce access control. This optional package is available in version 1.3.1, but has been included in the core SDK in version 1.4.0 onwards.

JAVACOMM is a set of packages that provide support for external devices connected through the PC's serial and parallel ports. If you don't need this functionality, you don't need to install it.

Setting up the Environment

After installation, you may want to put your Java directory into your PATH. This is not a strict requirement, and you can still execute the Java compiler and interpreter in their respective directories, but it *is* a good idea if you're doing development work because it makes things a lot more convenient. My recommendation is to setup a JAVA_HOME variable (why JAVA_HOME ? Because Apache Tomcat uses that variable name to reference the Java SDK or JRE) pointing to your Java directory, then put the bin directory into the $PATH. Here's what I mean: As root, edit /etc/profile. If you are using version 1.4.1, add the following lines :

# Java environment variables
export JAVA_HOME=/opt/IBMJava2-141
export PATH=$PATH:$JAVA_HOME/bin:$JAVA_HOME/jre/bin

If you are using version 1.3.1, add the following lines :

# Java environment variables
export JAVA_HOME=/opt/IBMJava2-131
export CLASSPATH=$JAVA_HOME/jre/lib/rt.jar
export PATH=$PATH:$JAVA_HOME/bin:$JAVA_HOME/jre/bin

Note that for version 1.3.1, I have explicitly set the CLASSPATH environment variable. There are some considerations about CLASSPATH for version 1.4.1, which are outlined in Appendix C.

You may want to reboot your system at this point to ensure that all changes to your configuration file are implemented.

Testing Your Installation

Now that you have the Java Development Kit installed on your system, it's time to test it out.

As root user, execute the following command,

# java -version

You should see some information about the Java SDK you installed including the build identifier. You may need to refer to this identifier if you find a bug in the SDK and wish to report it. Bug reports can be submitted to the IBM Java Linux newsgroup (Usenet server:, Groupname: You can also pick up a lot of useful information there, and even communicate with IBM employees directly related to the Java Development Kit.

Troubleshooting Your Installation

Still having trouble getting the IBM Development Kit running on your system ? You should download and read the SDK User Guide. Sometimes vital information for solving your problem can be found there.

There is a Diagnostic Guide that you can download from IBM, that may help you narrow down the scope of your problem. It can be downloaded from:

You can also pose your problem on the IBM newsgroup. You can subscribe to it here.

Where Do We Go From Here?

Sun Microsystems has redesigned their Java site so that now it is very accessible and a lot easier to navigate than before. Whatever your skill level, you can get useful tips and tutorials on different aspects and components of the Java 2 Platform. You can access the site at You might also want to sign up for their Java Tech Tips e-newsletter here.

Where I live and work, that is, in Asia, Java has a reputation for being complex, difficult to understand and maintain. This is true when compared to simpler scripting languages such as php, ColdFusion or Delphi (I would not say Visual Basic is easier, because I had to wrestle with memory problems and database connectivity when I was programming in VB). Certainly, you will need to spend some time getting up to speed on the language. After using it for about 4 years now, I still cannot claim to have mastered it, because it covers such a wide array of topics. There are 2 useful books that I would recommend to the Java newbie:

A lot of my Java education came from reading articles on IBM's DeveloperWorks, as well as JavaWorld. These are very useful resources, especially if you are short on time and need quick answers for a project.

Good luck and happy hacking in Java !

Appendix A. Segmentation Faults On gcc 3.x Systems

With Red Hat 9 and Fedora, you may encounter some puzzling segmentation faults or other errors when installing and using Java. These are mainly due to the more recent glibc libraries used, where the "floating stacks" feature is enabled by default. Floating stacks is a feature of the Native Posix Thread Library (NPTL).

To resolve this issue, there is an environment variable that you can set that will tell Linux whether to use the NPTL or not. That environment variable is LD_ASSUME_KERNEL, and you would put it in your startup file, such as your /etc/profile. Listed below are the two options you can use for LD_ASSUME_KERNEL.

Table 4. LD_ASSUME_KERNEL options

LD_ASSUME_KERNEL=2.4.19 Use Linux threads with floating stacks. You can use this if you wish to test if floating stacks work for your platform and Java version.
LD_ASSUME_KERNEL=2.2.5 Linux threads without floating stacks. If you keep getting segmentation faults, you should use this instead.

Need a hint on how to add the LD_ASSUME_KERNEL environment variable? I am using XFCE4 on my Red Hat 9 system, so my startup file is user-specific, and is .bashrc under my user directory. Below is my .bashrc file:

# .bashrc

# User specific aliases and functions

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc

# Java environment variables
export LD_ASSUME_KERNEL=2.2.5
export JAVA_HOME=/opt/IBMJava2-131
export PATH=$PATH:$JAVA_HOME/bin

When I was using KDE on Red Hat 9, I put LD_ASSUME_KERNEL inside my /etc/profile. Here is a snippet:

== preceding lines snipped away ==

USER="`id -un`"

# Java environment variables



== lines following snipped away ==

Note that in both examples, I am using version 1.3.1 of the Developer Kit. For version 1.4.1, there *should* be no need to add the LD_ASSUME_KERNEL environment variable.

Not all Java versions will bomb out on Red Hat/Fedora and Linuxes that use NPTL. Listed below are compatibilities I have tested.

Table 5. Compatibility of Java versions with Linux and NPTL

Java version RH9/Fedora/Linux with floating stacks enabled RH7/Linux without floating stacks enabled
1.3.1 LD_ASSUME_KERNEL=2.2.5 No changes necessary.
1.4.0 LD_ASSUME_KERNEL=2.2.5 No changes necessary.
1.4.1 No changes necessary. Have not tried.

Appendix B. Installing the Java Plug-In

For a lot of people, Java is only needed as a plug-in to the browser, to enable Java applets to run. Installing the Plug-In is not a trivial task. If you are using version 1.4 or better of the Mozilla browser, you will need a Java version that is compiled with gcc 3.x. Most Java versions are compiled with gcc 2.9x, and so, most Java versions do not have a plug-in that will run with Mozilla 1.4 or better.

If you want to run Java inside Mozilla 1.4+, you will need to download Blackdown's Java Runtime Environment. The install package can be downloaded from here :

Make sure that you download the Java version that is compiled with gcc 3.x. At the time of this writing, that package would be j2re-1.4.1-01-linux-i586-gcc3.2.bin. If you are having difficulty finding the file, it should be under the following directory: Some ftp sites will truncate the filename, so you will need to initiate the download first, then check the filename of the package you are downloading to verify that it is correct.

Once downloaded, copy the package to the directory of your choice and change the package into an executable file, then initiate the install. The steps below illustrate this:

# cp j2re-1.4.1-01-linux-i586-gcc3.2.bin /opt
# cd /opt
# chmod +x j2re-1.4.1-01-linux-i586-gcc3.2.bin
# ./j2re-1.4.1-01-linux-i586-gcc3.2.bin

You will be prompted to accept the licence and then the files will be unpackaged into the directory.

After installation completes, you will need to make a symbolic link to your Mozilla plug-in directory. Assuming that Mozilla is installed under /opt/mozilla, your plug-in directory becomes /opt/mozilla/plugins/.

# ln -s /opt/j2re1.4.1/plugin/i386/mozilla/ /opt/mozilla/plugins/

After you have done that, open Mozilla and click on "Help" and "About Plugins". You should see Java registered as one of the plug-ins recognized by Mozilla.

IBM's version 1.4.1 Java comes with plug-in files that should work with Mozilla 1.4 and better, but I have not tried them. If you have tried them successfully, please write me !

Appendix C. Classpath Considerations for version 1.4.x and 1.3.1

There are some significant changes going from version 1.3.x to 1.4.x for the IBM Java Development Kit. For 1.3.x and earlier versions, there is a file called rt.jar that sometimes needs to be explicitly included inside the CLASSPATH environment variable. Previously, this was necessary for Linux systems running double-byte language localizations, such as Japanese, Korean or Chinese. It was sometimes necessary when the Java Plug-In fails to be recognized by Mozilla.

In Sun's Java SDK, the file rt.jar is present in all versions including 1.4.1 (to my knowledge anyway). For IBM's Java SDK, this file no longer exists from version 1.4.0 onwards. Instead, this humongous file is broken up into several smaller files, such as graphics.jar, security.jar, server.jar, etc. This can sometimes cause problems with IDEs that try to autodetect your CLASSPATH. Earlier versions of Eclipse had this problem, but from version 2.1.1 onwards, this seems to have been resolved.

You should not need to declare your CLASSPATH explicitly for rt.jar or their component files, for version 1.4.1. You will need to declare additional libraries, such as JDBC drivers, etc., inside the CLASSPATH though. There are some other considerations, though, and these are covered in the SDK User Guide README.