This chapter introduces the IBM Java Software Development Kit. It does so mainly by pointing out how completely the kit mimics the Sun Java Software Development Kit covered in Chapter 5. Some time is spent on the minor differences and some installation issues.
The small number of important differences between the IBM and Sun Java Software Development Kits.
How to put more than one version of Java on the same development machine and how to switch between them painlessly.
We did not spend much time discussing the installation of Java on your Linux system in previous chapter. In fact, we did not discuss it at all. This is because the installation instructions that come with the SDK are more than adequate if you wish only to install a single Java SDK. But what if you want to install, say, both the Sun Java SDK and the IBM Java SDK? Then things get a bit more interesting.
We’re going to review the concept of filesystem links, and how they work on Linux. While it may seem odd to discuss them here, we’ll be using links to switch gracefully between different Java installations. Links are a powerful feature in Linux filesystems, and switching SDKs is a good application thereof. If you’re already familiar with links, skip ahead to Section 6.2.2.
A link is simply a name attached to a collection of data—that is, to a file. In other words, every file has one set of data and at least one link (a name). But a file may have more than one link. In other words, two different filenames may point to the same data. When you do this, you appear to have two copies of the file, but a change to one also changes the other. Deleting one, however, does not delete the other. It merely deletes the link. The file itself is only deleted when the last link is gone.
Links come in two flavors: hard and symbolic. A hard link looks like a file in and of itself. Let’s show you a hard link, before and after.
$ ls -la total 12 drwxrwxr-x 2 mschwarz mschwarz 4096 Jul 8 10:11 . drwx------ 50 mschwarz mschwarz 4096 Jul 8 10:11 .. -rw-rw-r-- 1 mschwarz mschwarz 45 Jul 8 10:11 sample $ cat sample This is a sample file to demonstrate links. $
As you can see, we have a directory with a single file in it, sample. Now let’s make a hard link to that file.
$ ln sample example $ ls -la total 16 drwxrwxr-x 2 mschwarz mschwarz 4096 Jul 8 10:13 . drwx------ 50 mschwarz mschwarz 4096 Jul 8 10:11 .. -rw-rw-r-- 2 mschwarz mschwarz 45 Jul 8 10:11 example -rw-rw-r-- 2 mschwarz mschwarz 45 Jul 8 10:11 sample $ cat example This is a sample file to demonstrate links. $
Notice a few things here. First, other than the size and timestamps being the same, there is nothing obvious to show that these two files are, in fact, the same file. Note also the number just ahead of the owning user and group names. In the first directory listing, sample had 1 in that position; now both sample and example have 2. This number is the link count. It tells you how many names are linked to the data associated with this name.
We have a couple more things to point out before we move on to soft links, which are going to be more important for our purposes.
$ chgrp wwwdev example $ ls -la total 16 drwxrwxr-x 2 mschwarz mschwarz 4096 Jul 8 10:13 . drwx------ 50 mschwarz mschwarz 4096 Jul 8 10:11 .. -rw-rw-r-- 2 mschwarz wwwdev 45 Jul 8 10:11 example -rw-rw-r-- 2 mschwarz wwwdev 45 Jul 8 10:11 sample $ chmod o-r example $ ls -la total 16 drwxrwxr-x 2 mschwarz mschwarz 4096 Jul 8 10:13 . drwx------ 50 mschwarz mschwarz 4096 Jul 8 10:11 .. -rw-rw---- 2 mschwarz wwwdev 45 Jul 8 10:11 example -rw-rw---- 2 mschwarz wwwdev 45 Jul 8 10:11 sample $ chgrp mschwarz sample $ ls -la total 16 drwxrwxr-x 2 mschwarz mschwarz 4096 Jul 8 10:13 . drwx------ 50 mschwarz mschwarz 4096 Jul 8 10:11 .. -rw-rw---- 2 mschwarz mschwarz 45 Jul 8 10:11 example -rw-rw---- 2 mschwarz mschwarz 45 Jul 8 10:11 sample $
As you can see, a file can have only one set of owners and permissions, no matter how many links are made to it. Changing the owner or permissions of one link changes all hard links at the same time. In other words, the security of a file is like its data: A change to one link is a change to them all.
A link need not be in the same directory as the original name.
$ ln example /tmp/sample $ ls -la total 16 drwxrwxr-x 2 mschwarz mschwarz 4096 Jul 8 10:13 . drwx------ 50 mschwarz mschwarz 4096 Jul 8 10:11 .. -rw-rw---- 3 mschwarz mschwarz 45 Jul 8 10:11 example -rw-rw---- 3 mschwarz mschwarz 45 Jul 8 10:11 sample $ ls -la /tmp total 132 drwxrwxr-x 2 mschwarz mschwarz 4096 Jul 8 10:23 . drwx------ 50 mschwarz mschwarz 4096 Jul 8 10:11 .. -rw-rw-r-- 1 mschwarz mschwarz 118081 Jun 3 18:51 jLin.tar.gz -rw-rw---- 3 mschwarz mschwarz 45 Jul 8 10:11 sample $
Here we made a third link in a different directory; /tmp/sample is a third name for the same data file. Note that we made it from the example link, not the original filename. In fact, as far as the Linux filesystem is concerned, there is no “original” name. None of these names is more significant than any other. When you remove a filename, the link is destroyed and the file’s link count is decremented. If the link count goes to zero, the file is removed. That’s it. Nothing else.
Hard links have a couple of drawbacks. One of them is a genuine technical limitation and the other is more of a usability problem. The technical limitation is that a hard link cannot be made across mounted filesystems. In the simplest case (we don’t want to muddy the waters with LVM[1] or RAID[2] at this point—most Linux distributions do not do LVM or RAID “out-of-the-box”), if you have more than one partition or disk drive, these are “mounted” at different points on the directory tree. For example, Mr. Schwarz’s laptop’s mount table looks like this:
$ mount /dev/hda2 on / type ext3 (rw) none on /proc type proc (rw) usbdevfs on /proc/bus/usb type usbdevfs (rw) /dev/hda1 on /boot type ext3 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) none on /dev/shm type tmpfs (rw) $
We have one large partition mounted at /, or root, and a small partition mounted at /boot. In all of our hard link examples so far, we have been making links on the root filesystem. Example 6.1 shows what happens when an attempt is made to hardlink between two different mounted devices.
This is what we mean when we say a link cannot cross filesystems.[3]
The other problem is more “touchy-feely.” With a hard link, you can see by the link count that other links exist, but you don’t know where they are. Symbolic links get you around both of these issues.
In a sense, symbolic links are much simpler than hard links. A symbolic link is a file that contains the name of another file or directory. Because it is marked as a symbolic link, the system will replace it with the contents of the linked file. Example 6.2 will make this more clear.
Example 6.1. Attempt to hardlink between mounts
$ ln example /boot/sample ln: creating hard link `/boot/sample' to `example': Invalid cross-device link $
Example 6.2. Symlinking /etc/passwd
$ ls -la total 8 drwxrwxr-x 2 mschwarz mschwarz 4096 Jul 8 15:30 . drwx------ 50 mschwarz mschwarz 4096 Jul 8 15:29 .. $ ln -sf /etc/passwd passwd $ ls -la total 8 drwxrwxr-x 2 mschwarz mschwarz 4096 Jul 8 15:31 . drwx------ 50 mschwarz mschwarz 4096 Jul 8 15:29 .. lrwxrwxrwx 1 mschwarz mschwarz 11 Jul 8 15:31 passwd -> /etc/passwd $ cat passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin ... etc.
What we did here works just like a hard link, but note the attributes on the file: The l indicates a symbolic link, and the permissions are read/write/execute for user, group, and other (or for “world” for short). However, these permissions apply to the link, not to the file. Just as with hard links, there is only one set of permissions on the file, and these are on the file that is pointed to, not on the pointer.
One interesting difference between symlinks and hard links is that symlinks do not increment the link count on a file. If we remove /etc/password (a very bad idea, by the way), the symlink would be unaffected, but an attempt to open or read the symlink would not work, because it points at nothing that exists. This is called a dangling symlink.
Symlinks may refer to symlinks, and thus you need to be cautious to avoid circular symlink chains. All the shells we have used on Linux report circular symlinks as “too many levels of symbolic links,” which sounds like a process exceeding its stack limits but handling it gracefully.
Here is the process we went through to install both Sun’s Java 2 SDK and IBM’s Java 2 SDK on a system at the same time.
Download the Sun JDK as a compressed TAR file.
Install it to
/usr/java. The Sun installer named its directoryj2sdk1.4.1_02, so the full path is/usr/java/j2sdk1.4.1_02.Download the IBM JDK and untar it also in
/usr/java. The base directory in the TAR file wasIBMJava2-141, so the path is/usr/java/IBMJava2-141.Create a symlink called
jdkin/usr/javaand make it point at the Sun JDK by default (Example 6.3).Add
/usr/java/jdk/binto the system’s defaultPATHenvironment variable.[4] Also addJAVA_HOMEandJDK_HOMEenvironment variables that point to/usr/java/jdk.
Now when we run javac or any other Java command, we run the version which is pointed to by the jdk symlink. If we wish to switch to the IBM JDK, we can just replace the link as show in Example 6.4.
From then on, the machine will be using the IBM Java SDK.
And, of course, by explicitly setting the path and environment variables, you can use whatever you prefer without changing the symlink for all other users on the system. This is an excellent example of how the features of the Linux system can make your life as a Java developer easier—with this general method, you can keep as many Java SDKs from as many vendors as you wish and switch between them at will.
Here, we showed you how to do this on a system-wide basis, but you could, by creating the symlink in your home directory and changing the path for your user account, switch between versions in your own account only, leaving the system-wide default alone. Linux provides endless flexibility for developers.
Example 6.3. Symlinking jdk to the Sun Java SDK
# ln -s j2sdk1.4.1_02 jdk # ls -la total 16 drwxr-xr-x 4 root root 4096 Jul 8 15:51 . drwxr-xr-x 17 root root 4096 Jun 17 10:18 .. drwxr-xr-x 8 root root 4096 May 21 21:09 IBMJava2-141 drwxr-xr-x 8 root root 4096 Mar 5 14:44 j2sdk1.4.1_02 lrwxrwxrwx 1 root root 14 Jul 7 22:33 jdk -> j2sdk1.4.1_02 #
Example 6.4. Symlinking jdk to the IBM Java SDK
# rm jdk # ln -s IBMJava2-141 jdk # ls -la total 16 drwxr-xr-x 4 root root 4096 Jul 8 15:51 . drwxr-xr-x 17 root root 4096 Jun 17 10:18 .. drwxr-xr-x 8 root root 4096 May 21 21:09 IBMJava2-141 drwxr-xr-x 8 root root 4096 Mar 5 14:44 j2sdk1.4.1_02 lrwxrwxrwx 1 root root 14 Jul 7 22:33 jdk -> IBMJava2-141 #
After the last chapter, which was one of the longest in the book, this chapter should come as something of a relief. It is one of the shortest in the book. Why? Because the IBM Java Software Development Kit is practically identical in use to the Sun package. It differs in only a few respects and that is all we will talk about here.
One of the biggest differences is the version of Java available from each vendor. Sun has the newest versions, as they have been defining what those are. IBM is still releasing the 1.3 versions of Java as Sun begins to release 5.0. But you may not want or need the “bleeding edge” of the technology.
IBM’s Java implementation appears to run most code faster than the Sun implementation. Benchmarking something as complex as a Java Virtual Machine is well beyond our scope here (and, in fact, coming up with a benchmark that will actually predict how much faster your application will run on one environment versus another is practically impossible). Nonetheless, we have seen some fairly dramatic performance improvements when running Java applications under the IBM JVM—improvements on the order of 50%–100%.
It is interesting to note that it does not matter which Java SDK produced the bytecode files. We see these improvements when the compiled classes are run, no matter which compiler (IBM’s or Sun’s) was used to produce them. This suggests that it is some combination of a faster virtual machine and/or a better Just-In-Time compiler (JIT) that gives IBM’s runtime its apparent performance advantage.
For the most part, we use the Sun development kit and runtime, simply because Sun’s is the definition of Java. But if execution speed is proving to be critical for your application, consider the IBM Java runtime. You may see some speed advantages.
You will notice a few differences. For example, there is both a java and a javaw. Both invoke the Java runtime. The former has the Java console interface, the latter does not. For our purposes, this does not matter. The IBM Java SDK comes with an Object Request Broker Daemon (orbd) for CORBA/IIOP while the Sun SDK does not. Again, for our purposes this doesn’t matter.
For the bulk of the utilities, the differences are so slight that you can use the Sun documentation for the IBM tools.
IBM’s Eclipse project (which we begin to cover in Chapter 10) provides a large GUI API library called SWT. We won’t go into that here; it is covered in Chapter 17. Of more immediate interest is IBM’s enhanced BigDecimal class (com.ibm.math.BigDecimal) which addresses a lot of deficiencies in Sun’s implementation of decimal arithmetic. We will be using the standard Java class in our book (as it is the same for all development kits we cover), but you might want to take a look at IBM’s FAQ document on their enhanced BigDecimal class.[5] It also appears that IBM’s class may become the official Sun version in Java 5.0 when it comes out. The primary feature of this class is its ability to deal correctly with rounding and precision, which is of great benefit in financial and scientific applications. Check out IBM’s documentation and see if this is something you should use.
Note that Java bytecodes are Java bytecodes. You can download and use the IBM class with the Sun Java Runtime. It is there if you need it.
One thing you will notice right away when you unpack the IBM Java SDK is that it has virtually all of the same commands as does the Sun Java SDK, but there is a whole bunch of them duplicated with a mysterious “_g” suffix. What’s up with that?
These versions run a Java VM that was compiled with debug information, so that you can report information about bugs and errors that is of use to IBM SDK developers in locating and fixing problems. These versions should not be used for production work, but only to recreate and report bugs.
Well, we told you this one would be short. With a handful of minor exceptions, the IBM Java SDK is a complete drop-in replacement for the Sun Java SDK. You could go back to the previous chapter and repeat every example and exercise with the IBM Java SDK, and you would get the same results. There is definitely some comfort in knowing that even though you don’t have an Open Source Java VM and SDK, at least you have two vendors the produce functionally identical development environments. You are not trapped into a single vendor’s offering.
What you still don’t know after reading this chapter is similar to what you still didn’t know after reading Chapter 5. IBM Java SDK has many things we have not covered, including security policy files, JNI, and RMI.
The best source of information about IBM’s Java technology is IBM itself. Search the alphaWorks section of their Web site; we used http://www.alphaworks.ibm.com/nav/java?openc=java+-+Developer+Kits and found entries for the Java 1.3 Development Kit for Linux, as well as other Java-related downloads, including the Jikes Open Source compiler.
[1] Logical Volume Manager. This is a tool that lets you arbitrarily aggregate disk drives and partitions into a “logical volume” that may be mounted and unmounted as a unit. Such tools are commonly used in serious production servers, but are rare on workstations or simple Linux servers.
[2] Redundant Array of Inexpensive Disks. Another heavy server feature that allows multiple disk drives to be linked up as if they were a single disk drive and to act as backup to one another silently and transparently.
[3] In a similar vein, there are some networked filesystems that do not support hard links at all because the server or host system doesn’t support the concept. Attempts to make links on or to such systems will also fail.
[4] Exactly where you do this depends on your distribution. If you aren’t sure, you can always do it in the .bash_profile file in your user account’s home directory.