One of the frustrating things for people who write articles and documentation on Java and Linux is the speed at which the platforms evolve. Looking at my previous contributions to this Java section, I am amazed that almost all the information has become obsolete. This is not necessarily a bad thing for software developers, because later versions normally offer either more functionality (such as support for messaging and naming services), or more focus and market relevance.
The IBM Development Kit typically lags behind Sun's product release cycle, with version 1.4 released only very recently. It is compatible with Sun's Java implementation and, some say, it is faster. I personally prefer IBM's implementation for philosophical reasons that I won't go into here.0.2 Current Version
The latest version is : 1.3.1, J2RE 1.3.1 IBM build cxia32131-200211020.3 Tested Platform
These procedures were tested on Probatus Spectra Linux 1.2, but should work on all other Linuxes that support RPMs. Tar files are available as well from the same IBM download site.1.0 System Requirements
The minimum requirements for getting IBM's Java to run on your Linux are :
I have successfully tested IBM's Java 1.3.1 on TurboLinux Workstation 7, TurboLinux Server 7 and 8, and am currently using it on Probatus Spectra Linux 18.104.22.168 Downloading the Latest Version
You will need to register for an IBM DeveloperWorks account before downloading. The Java SDK comes in 2 package types : you have a choice of downloading the rpm or compressed tar file. There is a facility on the download site, called Download Director that is supposed to manage the download for you. Trouble is, it requires Java to run, and if you're downloading Java for the first time, well, that would not work, will it ? :)
My recommendation is the rpm because it is easier to install and uninstall -- you'll be doing quite a bit of that as service releases are quite frequent. No, the Java SDK is NOT riddled with bugs. I have used IBM's Java SDK to develop a billing program that does mathematical computation and string manipulation on an extremely large (to me, anyway) data set (about 700MB), and I've found that it holds up very well.
There are some caveats, though. Such as, if you are running Red Hat (see Appendix B) or if you're trying to run on SMP machines with the JIT (Just-In-Time compiler) enabled.
The latest versions of IBM's Java SDK, JRE and related technologies can be found here.3.0 Uninstalling existing versions
If you already have an earlier version of IBM's Java SDK installed, you have to first remove it. As root, execute the following commands :
# 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.4.0 Installing the latest version
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 other components.
JAAS is the Java Authentication and Authorization Service which enables services to authenticate and enforce access control.
JAVACOMM is a set of packages that provide support for external devices connected through the PC's serial and parallel ports.5.0 Setting Up The Environment
One last thing : 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.
Add the following lines :
# Java environment variables
The documentation says that you don't need to setup a $CLASSPATH. If you are using RedHat, Caldera (now SCO) or any English(US or UK) version of any Linux distros, setting the $CLASSPATH is probably not necessary. For TurboLinux and Chinese/Korean/Japanese versions of any Linux distros, it's probably a good idea to set it, because Java may not work without it. In any case, when you want to add third-party Java classes, you'll need to set it up anyway.
You will need to save the file /etc/profile after your modifications and, for the changes to take effect, you should reboot the system.5.0 Testing Your Installation
Now, we check if everything has been setup correctly. As root, try 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: news.software.ibm.com, Groupname: ibm.software.java.linux). You can also pick up a lot of useful information there, and even communicate with IBM employees directly related to the Java Development Kit.6.0 Installing the Java Plugin on Netscape/Mozilla
These instructions are for Mozilla 1.x and Netscape 7. If you are using earlier versions, isn't it time you upgraded ? :) But seriously, there are a lot of good things to be said about Netscape's latest browser, such as proper rendering of stylesheets and standards compliance (to some degree). When Netscape 6 first came out, I didn't like it much because it seemed bloated and buggy, but Netscape 7 is a LOT better.
The instructions included in IBM's Java Development Kit is not really complete, regarding the Java Plugin. It may work on Red Hat, but, personally, it hasn't turned out all that well on TurboLinux. The way to install it is as follows :
For IBM's Java Plugin, there are 2 things you must do:
First, You need to put the file rt.jar into the $CLASSPATH. To do this, open /etc/profile again and add the following line into your $CLASSPATH:
Next, you will need to make a symbolic link for the Java Plugin to Mozilla's plugin directory.
Assuming that Mozilla is installed into /opt/mozilla, as root, execute the following command :
# ln -s /opt/IBMJava2-131/jre/bin/libjavaplugin_oji.so /opt/mozilla/plugins/libjavaplugin_oji.so
Important Note: Don't try any shortcuts here, such as not specifying the destination fully -- you must specify the filename for the symbolic link, not just the directory! Even though the symbolic link will appear in Mozilla's plugin directory, Mozilla will not recognize it. If you execute Mozilla from the console you will get an error about the symbolic link!
The changes should be reflected immediately. If you start Mozilla after this, it should recognize that the Java Plugin is installed.
One last thing: for some versions, you may get a "Bus error" or some kind of failure that will cause Mozilla or Netscape to bomb out the first time you start the application after making the changes. This is OK! Just start it again, and you should not have any more problems with the browser.
How can you tell if the Plugin installed successfully? Just key in "about:plugins" into the text box where you normally type the URL and hit enter. This will give you a list of plugins that Mozilla recognizes as installed. Or, you can just go to this page, -- there is an applet there that should work, if your plugin is working properly. Otherwise, you will just get another error message asking you to download the Java plugin. Check through the instructions in this article again and see if you missed anything.
Some Linux distributions already use gcc 3, and one posting on the IBM newsgroup asked if IBM's Java was supported on these platforms. This is the reply from IBM :
============= Reply from Mike Edwards, IBM, on 01/06/2003 =============
We are looking at using gcc 3.2 to compile our future 1.4.x Java SDKs.
However, the 1.3.1 Java SDKs are compiled using gcc 2.95 and we have no plans to compile with anything later than this for these SDKs. If you use gcc 3.2 to compile native code that you then call from a Java application that runs on one of the 1.3.1 SDKs, I predict that you will run into trouble, due to incompatibilities in the libraries.
Unfortunately, the migration from gcc 2.95 to gcc 3.x is not trivial for the Java SDKs and we are unable to support both compilers with a single Java SDK.
The text below is reproduced from the README file that comes with the IBM Java Development Kit. I have included it here because people normally do not read the documentation that accompanies the software. I'm guilty of this myself.
============= From $JAVA_HOME/docs/README-EN.JRE.HTML =============
Certain Linux distributions - RedHat, for example - have enabled a GLIBC feature called 'floating stacks'. Because of Linux kernel limitations, the JVM will not run on SMP hardware with floating stacks enabled if the kernel level is less than 2.4.10. In this environment, floating stacks must be disabled before the JVM, or any application that starts the JVM, is started. On RedHat, you disable floating stacks by exporting an environment variable, thus:
On a non-floating stack Linux system, regardless of what is set for -Xss, a minimum native stack size of 256KB for each thread is provided. On a floating stack Linux system, the -Xss values are honored. Thus, if you are migrating from a non-floating stack Linux system, you must ensure that any -Xss values are large enough and are not relying on a minimum of 256KB.