Java[tm] Technology on the Linux Platform

Print-friendly Version

Articles Index | Programming Index

The availability of the Java 2 Platform Standard Edition (J2SE technology) v1.3 for Linux means that Linux users and developers will be able to take advantage of thousands of Java technology-based applications, from enterprise e-commerce infrastructure to client-side applications.

In an ideal world, the Java 2 Platform, in combination with Java development tools such as Forte Community Edition, should be all you need to successfully develop your projects. However, if the Linux operating system is a new development environment for you and you have previously developed with the Java 2 Platform for Windows or Solaris, you might find that using Linux is a little different from what you are used to. This article provides useful tips to help you come up to speed as quickly as possible developing on the Linux platform.

SDK and JRE Installation Tips

Installation is straightforward, but you should be aware that the Java Runtime Environment (JRE) and Java Software Developer Toolkit (SDK) Red Hat package files (rpm) are installed by default to /usr/java. If you want these files in a different location, install with the the rpm command as follows:

rpm -i  --badreloc --relocate /usr/java/=/usr/local/home j2sdk-1_3_0-linux.rpm

After relocating the files as shown above, all you need to do to start developing is add the bin directory from the SDK or JRE installation to your $PATH. Linux distributions maintain a database of all packages you install, which makes it easy to update the $PATH. For example, using the bash shell, the $PATH is updated as follows:

export PATH=/usr/java/jdk1.3/bin:$PATH

To verify that you have configured your environment, run the java -version command, and you should see a version string confirming that you have installed the Java^TM 2 Runtime Environment.

java -version

java version "1.3.0"
Java 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot Client VM (build 1.3.0, mixed mode)        

Java Plug-in Installation Tips

The Java 2 Release 1.3 Plug-in is embedded inside the Java Runtime directory. This means that as long as the Netscape browser can find the plug-in library from within the Java Runtime directory, it can also work out where to find the additional runtime files it needs.

To let your Netscape browser know where the Java plug-in library is, set the NPX_PLUGIN_PATH environment variable to point to the directory where the javaplugin.so shared library is located as follows:

export NPX_PLUGIN_PATH=/usr/java/jdk1.3/jre/plugin/i386

To configure the Java plug-in properties, use the ControlPanel program located in the jre/bin directory. In the example above the program is /usr/java/jdk1.3/jre/bin/ControlPanel.

Hotspot Virtual Machine

This is the first release on Linux that includes the Hotspot virtual machine. Both the client and server Hotspot compilers are included in the Java Runtime Environment.

By default the client compiler is enabled, but for intense server-side applications, you can run the server compiler with the -server runtime option. The Hotspot virtual machine normally runs in a mixed mode, as seen in the -version output. Mixed mode means Hotspot dynamically compiles Java bytecodes into native code when a number of criteria have been met, including the number of times the method has been run through the interpreter. Mixed runtime mode normally results in the best performance.

About Linux Threads

One major difference between developing on Linux from other Unix operating systems is the system threads library. In Java 2 releases prior to 1.3, the Java virtual machine uses its own threads library, known as green threads, to implement threads in the Java platform. The advantage here is that green threads minimize the Java virtual machine's exposure to differences in the Linux threads library and makes the port easier to complete. The downside is that using green threads means system threads on Linux are not taken advantage of and so the Java virtual machine is not scalable when additional CPUs are added.

In Java 2 Release 1.3, the Hotspot virtual machine uses system threads to implement Java threads. Because Linux threads are implemented as a cloned process, each Java thread shows up in the process table if you run the ps command. This is normal behavior on Linux.

java -jar Notepad.jar
ps -eo pid,ppid,command 

  PID  PPID COMMAND                            
11667 28367 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar
11712 11667 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar   
11713 11712 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar
11714 11712 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar
11715 11712 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar
11716 11712 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar
11717 11712 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar
11718 11712 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar
11722 11712 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar
11723 11712 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar
11724 11712 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar
11726 11712 /usr/java/jdk1.3/bin/i386/native_threads/java -jar Notepad.jar

In the above listing, the process ID 11712 shown in the left-most PID column is the invoked Java virtual machine. The other processes that show process ID 11712 in the PPID column have process ID 11712 as their parent process. These children to process ID 11712 are Java threads implemented by the Linux system threads library. Each Linux thread is created as a process clone operation, which leaves the scheduling of threads to be a task of the process scheduler.

By comparison, on Solaris the Java threads are mapped onto user threads, which in turn are run on Lightweight processes (LWP). On Windows the threads are created inside the process itself. For this reason, creating a large number of Java threads on Solaris and Windows today is faster than on Linux. This means you might need to adjust programs that rely on platform-specific timing to take a little longer on startup when they run on Linux.

Generating a Java stack trace on Linux

As you learned in the section on threads, Linux threads are implemented as Linux processes. This makes debugging Java programs running on Linux a little different. To generate a stack trace from the terminal window where you started your application, you only need to type the sequence <CTRL>/ to send the QUIT signal to generate a stack trace. However, if you need to generate a stack trace from a Java application already running in the background, you need to send QUIT or signal number 3 to the launcher process ID. The launcher process in this example is process ID 11667. The stack trace can be generated by sending the signal via the kill command as follows:

kill -3 11667

The resulting stack trace will be a snapshot of the Java threads in the main threads which details the state of each thread. This information can be used to track down deadlocks or busy sections in your application. For more details on analyzing Java stack traces, refer to the Debugging Applets, Applications, and Servlets chapter in Advanced Programming for the Java 2 Platform (Addison-Wesley, 2000).

Desktop Differences (Copy and Paste)

If you have been using Windows or a keyboard with a copy and paste key, you might be wondering how to copy and paste text between Java programs and other desktop programs and terminals.

Linux uses a mouse-driven copy and paste mechanism where mouse button one selects and copies text, and mouse button two pastes the text. This technique works for Abstract Window Toolkit (AWT) components because they use the primary selection to achieve copy and paste. Project Swing components, however, use the system clipboard for copy and paste, and most tools on the desktop, apart from the Netscape browser, do not use the clipboard.

A workaround to this limitation is to map a key or mouse button to access the system clipboard as follows:

*VT100.Translations: #override \
            <Btn3Up>:                select-end(CLIPBOARD) \n\
            <Btn2Up>:                insert-selection(CLIPBOARD) \n

The above lines can be passed as a value to an X tool using the -xrm option. Alternatively, the mapping can be made accessible to the entire desktop by including them in the .Xdefaults file in the user's home directory. The command xrdb -merge $HOME/.Xdefaults will reload updates in the .Xdefaults file.

In Summary

Using Linux to develop and deploy applications written in the Java programming language has the same benefits as developing on any Java platform. Thousands of Java programming language applications are already available, and because they are cross-platform, applications compiled on Linux will work right out of the box on Windows or any other Java-enabled platform.

In addition, the amount of Linux knowledge needed to develop or deploy Java programming language applications on Linux is relatively small, which makes adding Linux as a development platform an attractive choice.

Calvin Austin, is the lead staff engineer for the Java 2 Standard Edition Linux project at Sun Microsystems, Inc., and works with the Blackdown.org Java porting group. He is co-founder of the Java Developer Connection, and also the co-author of Advanced Programming for the Java 2 Platform (Addison-Wesley, 2000).

¹ As used on this web site, the terms Java virtual machine or Java VM mean a virtual machine for the Java platform.