It should be pretty trivial to install Java on Linux. But there are different aspects like installing the JDK, installing the plug-in for the Browser, and installing a Web Container. If you have a commercial Web Container, I figure the vendor will provide documentation and support.

Installing the Java Development Kit - JDK

• Really basic. Just go to http://java.sun.com/ and download the JDK for Linux. Most modern distributions are supported since Kernel 2.2 but really folks should be on kernel 2.4.x and later. Requirements are about 150 MBs of disk if you unpack everything. Typically to support Mozilla running, XF86 windowing, and javac, you need at least 128 MBs of runtime memory, but I really recommend splurging and going with 256 Megs or more. It'll save a lot of headache on paging when you run low.

• The download is a self-extracting binary with a .bin suffix. Move it to the directory you want it to unpack into. Then chmod 755 the file to make it executable or just shell exec it. I usually put all my JDKs into /opt. You can download previous JDK releases as well. It's good as a developer to have multiple versions. I rename the unpacked directory from /opt/j2sdk-x-y-z- to /opt/jdk1.x.y_0z where x is the major revision, y the minor revision and z the sub release. Test the install by running at a shell command line the /opt/jdk1.4.2_01/bin/java -version

• Create a soft link called java that would always point to the directory where your new distribution starts (i.e.: /opt/java/ -> /opt/jdk1.4.2_01/ ). So, you don't need to change the directories' link names, every time that you upgrade Java. If all your java calls are directed to what this soft link called java points to, then when you upgrade, you just need to change this soft link to point to the new directory name. Then you will always call /opt/java/bin/java-version , no matter the name of your java upgrade is.

• Go into the unpacked directory, and if you plan on doing development, having source access is cool, so you'll want to unpack the src.jar. for example, you should see it at: /opt/jdk1.4.2_01/src.zip . Note: The folks at Sun Software have a nasty habit of packing the jar relative to the current working directory, so if you just unJar the zip file, you'll get bunch of subdirectories that clutter the main JDK distribution. So I recommend making a subdirectory mkdir ./src and just moving the src.zip file in there, and changing directories to ./src and then unzipping the src.zip file.

• For those of you planning on development on Linux, I recommend a couple of tips to set or not set in your shell startup scripts.
  • add environment vars JAVA_HOME and JDK_HOME in the shell start-up that point to the appropriate install dir
  • do NOT add an environment variable for CLASSPATH to the shell startup - the javac and java commands automagically do that
  • add $JAVA_HOME/bin to your path at the start to bypass the /usr/bin/java that's default installed with some Linux distros.
  • add shell aliases or shortcuts to change directories to $JAVA_HOME/src, or to set $CLASSPATH to an appropriate directory, and/or to compile with the -d $CLASSPATH. These shortcuts will help with repetitive command line development where you'll want to look at JDK source or to set and execution classpath for the JVM or to compile and deploy to a specific CLASSPATH.

• Here's an excerpt of some C-shell aliases I use. When I start up a new Java development directory, I make 2 subdirectories, ./src and ./classes. I put source files in the ./src directory, usually as a flat hierarchy. But I let Java's packaging mechanism rule over the structure of ./classes. I also copy and unpack and needed JAR files into ./classes for development rather than editing the mother-of-all CLASSPATHs. Your mileage may vary. This is just my way to simplify my life.

        alias  a       alias
        a       jc      'javac -d $CLASSPATH'
        a       jh      'java -Djava.awt.headless=true'
        a       setcp   'setenv CLASSPATH $cwd/classes'
        a       unsetcp 'unsetenv CLASSPATH'
        a       src     'cd $JAVA_HOME/src/java'

Installing the Plug-In for the Browser

I'm going to assume that most of you folks run Mozilla most of the time. If you're running Konqueror or something else, well, I'm not the one to contact for JVM and applet support. I've written a fast scientific calculator, mortgage calculator, a Java Karaoke application, a 360 degree image viewer, and even a utility to space guide rings out when building a Fishing Rod! However, these are mostly applets. Since that's where I started with Java, I still think applets are great and could be even more useful. But to get them working in the latest browsers, you need to install the plug-ins. Not hard to do, but it seems like most of the docs never get to the point.

• Installing as Root for Everybody - If you want everyone to have the plug-in, then if you've got the JDK installed as defined above, just go to /usr/lib/mozilla or where your distro installs Netscape 7.x or Mozilla or later, and then make a symbolic link, for example: ln -s /opt/jdk1.4.2_01/jre/plugin/i386/ns610/libjavaplugin_oji.so . Now quit and restart the browser and check the plugin info in the Help->About Plugins Page.

• Installing as a User - If you don't have permissions to write to root, at least you can basically do the same thing by linking the plug-in from the JDK directory to the user standalone version of installed Mozilla. If you are running the root version of Mozilla but just want local plugins, sorry, but Mozilla is moving to a more MS style registry and you'll need to try to use the Preferences and Helper Applications link to install the plugin locally. Note that the lastest versions of Mozilla Firebird need a plugin compiled in gcc3.2.x, so you will need the JDK/JRE 1.4.2 and later for that. More information can be had at: http://plugindoc.mozdev.org/linux.html or read the next section.

• Redhat 7.3 Netscape 7.1 issues - If you're running older versions of Linux, for example, Redhat 7.3, and downloaded the latest Netscape 7.1 for Linux and then found that the applets are now not working, this is again due to the compilation of the latest Netscape 7.1 with gcc3.x. Older versions of the libjavaplugin_oji.so will fail to load. If you start Netscape at the command line, this should show some missing symbol error. You must upgrade to the latest jdk1.4.2 plugin. You can download it at http://java.sun.com/ . I've used ./jdk1.4.2_03/jre/plugin/i386/ns610-gcc3/libjavaplugin_oji.so. But upgrading the plugin alone will not activate Java in Netscape 7.1. With Redhat 7.3 and older versions, they shipped with gcc2.95 or earlier, and completely forgot to issue RPMs for gcc3. These RPMs, which ship on Redhat 8 and later, include a libgcc_s.so.1 shared library that is needed by the libjavaplugin_oji.so plugin. If you've already downloaded and compiled the gcc3.x distribution, then in the gcc-lib subdirectory, you should find the correct library, and just insure that the shared library file is in the LD_LIBRARY_PATH, or a trick that works is to create a symbolic link from the Netscape target install directory to the file. Note: You should see quite a few other shared library files in the Netscape Install Directory. If you do, that's the correct location to create the symbolic link. For folks who don't have libgcc_s.so.1 and need that file, you can download a gcc3 distribution from the web somewhere, or if you have access to a Redhat 8 system or later, you can access that system over the network and transfer a copy and deploy it inside the Netscape target install directory. Exit and restart Netscape and you should have no more errors loading the Java plugin.

Installing a Java Server - Tomcat

Again, fairly straightforward. Go to http://jakarta.apache.org/ and download the latest and follow their instructions to build/install and build the connector module. The real tricks are more pertaining to things like getting Linux to startup with Apache and Tomcat always.

• Getting Init.D to startup Tomcat - if you want the system to restart Tomcat and Apache each time Linux reboots, most likely you need to do two things. Make sure that you have a link to /etc/init.d/httpd in /etc/rc.d/rc3.d/S85httpd as well as /etc/rc.d/rc5.d/S85httpd. There are also the corresponding K15httpd files that must exist as well. But you have a very easy life if your Linux box supports the chkconfig utility. If it does and the /etc/init.d/httpd script has a line in the header comments:

         # chkconfig: - 85 15

      TOMCAT_HOME=/opt/jakarta-tomcat-4.0.6
      JAVA_HOME=/opt/jdk1.4.2_01

Modify to adopt to your version, whether that Tomcat3 or some other JDK version. Next, down in the startup script where the start) and stop) are actually executed, I add the 2 following TOMCAT lines:

       ...
       # See how we were called.
      case "$1" in
        start)
              start
              $TOMCAT_HOME/bin/startup.sh
              ;;
        stop)
              $TOMCAT_HOME/bin/shutdown.sh
              stop
              ;;

For security reasons, you should probably disable the HTTP10Connector line in the Tomcat server.xml file or at least configure Tomcat to accept HTTP conections only on 127.0.0.1. The reason should be clear. Since you may be developing server code that requires Basic Authentication and other security features, like SSL, it's better to channel that through Apache HTTPd which has had much more code review on security than the Java Server pages and Servlets stuff. You can also leverage Virtual Servers under Apache more clearly and not permit sharing, but that's for a different Wiki thread :-).

-- JamesCLiu - 22 Jan 2004