Setting Up A Java Development Enviroment For Linux LG #45

Contents

Obtaining the JDK

Kernel Support For Java

JDK

Java Beans

Swing

Java Accessibility Utilities

JSDK

Documentation

Java Tutorial

Sun’s HotJava Browser

Next Month

Introduction

This article is intended to help those new to either Linux or Java set their machines up to run Java applications, as well as providing an effective environment for developing new Java applications.

Specifically I shall explain how to set up Sun’s 1.1.x JDK and other related packages. This is not the only way to run Java on Linux.

Blackdown.org now offers the new 1.2.x JDK for Linux (at the time of writting this is still a pre-release version). I only recommend using this if you are also using the new 2.2.x Linux kernel. If you choose to install the 1.2.x JDK then please note that you do not need to obtain the Swing and JSDK packages, since they are already included. Also you may find some compatibility problems if you use older Java applications with the 1.2.x JDK. In particular if you intend to implement the javapache extensions to Apache you will need to use JDK 1.1.x.

In addition there exist other third party Java environments and Java compilers such as IBM’s jikes. Use these at your own peril! IMHO Sun have defined and developed the Java language so I expect their Java environments to be the most standard. Other environments may be of interest, but I cannot cover them here.

Unfortunately the development of the Java language for Linux lags the development for other operating systems. Having said that there are still many advantages to using Java on Linux, not least of which is the easy availability of sophisticated development tools. If you have not seen a recent version of DDD (The Dynamic Display De-bugger), you may not realise that it now supports Java. If you write any programs under Linux DDD is a must have utility.

Why use Java at all?

Java’s greatest advantage is also its greatest disadvantage. For reasons given below, the fact that the same Java code can be run on any platform without re-compiling is responsible for the fact that Java applications can appear slow. It is this slowness that has lead some to question the need to use Java at all.

It is true that if speed in loading and running an application is the only criteria for choosing a programming language then I would never consider using Java at all. Although applications such as jedit and the Java cd player described in earlier editions of this e-zine are functionaly equivalent to applications written in C they are very slow to start up and I am loath to use them when I have much faster alternatives.

But Java is not meant for such applications. Java excells in what it was originally designed for, which is to provide a means of making applications available over the Internet. Over the Internet the speed of loading an application is not really important when compared to the time it takes to download the application.

Now consider your friendly ISP, and the servers that provide you with Internet access. Your ISP (even your local Intranet) needs the fastest machines possible given certain criteria (cost etc). The cost of the actual server may not be important when compared to the software investment of server-side applications. Using Java to implement server-side applications leaves your ISP free to choose the best machine architecture and operating system without having to worry about the cost and feasibility of re-implementing such applications. They can simply be copied from one machine to another. Perhaps one day Microsoft will develop a reliable operating system that is superior to a *NIX operating system. If that day ever comes I will want to change from Linux, using Java will allow me to do that and keep exactly the same server-side applications I am running now.

If you only want to use a stand-alone computer, with no network access, either locally or over the Internet, then you probably do not need or want to consider using Java. But if your machine is going to be part of a local network or the Internet then the use of Java should be taken very seriously. Java is not the only way to develop network applications. For instance Perl can be used in a very similar way. But Java is a very attractive option.

Obtaining the JDK

Please do not obtain your JDK directly from Sun. They provide support only for Microsoft Windows, Solaris etc. Instead go to Blackdown.org and find the version you require.

All other packages mentioned here should be obtained from Sun.

The Linux port of the JDK can either be found on a Linux distribution disk, or can be found at http://blackdown.org. You will find you have a bewildering choice of files to install. There is the JRE as well as the JDK. I recommend you get the full JDK package since it contains everything in the others.

READ  hangulin

Kernel Support For Java

Linux was possibly the first operating system to provide direct kernel support for Java. This allows Linux to run both Java applications and Java applets directly, without the need for a browser such as Netscape. But if you think direct kernel support means that the kernel has anything to do with actually running Java code you are sadly mistaken.

To understand what is happening you need to realize that Java is really only one step removed from running interpreted programs rather than compiled programs. In the early days of computing, it was common to use an interpreted language, such as GW-BASIC, to write simple applications. The code that was written was never compiled into a program, rather the code would be parsed by an interpreter which would perform the actual execution of instructions. This is a very inefficient way of doing things and the results will always be slow.

Java differs from an interpreted language, such as early versions of BASIC, in that the source code is compiled. But the source is not compiled into something a computer can directly execute as would be the case if you compiled a C program with gcc. Instead the source code is byte-compiled into a standard format. The reason that the same Java application can be run on any platform is precisely because this byte-code is in a standard format. The programs java and appletviewer, provided by Sun or Blackdown.org perform the function of parsing this byte-code and executing the instructions. This is the reason Java applications can appear slow, the byte-code must be parsed by an interpreter before it can be executed, though the situation is not nearly as bad as it was with early BASIC programs, since the byte-code has already been optimized by the java compiler.

When you compile Java support into the Linux kernel what you are really doing is telling the operating system to invoke either java or appletviewer when a request is made to execute a java application. Linux is simply giving you a shorthand way of saying ‘appletviewer myapplication‘.

For this reason you need to tell the kernel where your Java executables are kept. If you obtain the JDK from Blackdown.org then the chances are that java and appletviewer will be placed in /usr/local/java/bin. If you install the JDK from a S.u.S.E. distribution disk then they will be in /usr/lib/java/bin. Of course you might have installed the JDK to some non-standard location.

Before you re-compile your Linux kernel, edit the file /usr/src/linux/fs/binfmt_java.c to reflect the situation you actually have.

 #include  #include  #define _PATH_JAVA "/usr/local/java/bin/java" // Replace with correct location for your system. #define _PATH_APPLET "/usr/local/java/bin/appletviewer"  // Replace with correct location for your system.
     #define _PATH_SH        "/bin/bash" 

     char binfmt_java_interpreter[65] = _PATH_JAVA; 
     char binfmt_java_appletviewer[65] = _PATH_APPLET; 

Please note that the references to java and appletviewer should be to the actual location of the binaries and not to any symbolic link you might have created. In the example above the directory /usr/local/java might be a symbolic link to /usr/lib/java-1.1.7, but the actual file refereed to is not a symbolic link, it actually exists in /usr/lib/java-1.1.7/bin.

Now you can decide if you want to compile Java support directly into the kernel, or have it as a module. I choose to use a module. The only comment I feel necessary is that when I try to execute a html file kernld will not automatically load the binfmt_java module, so I must « insmod binfmt_java » first.

Execute a HTML file?

Yes, Linux will allow you to execute certain HTML files as though they are applications. To understand why you would want to do this you need to understand the difference between a Java applet and a full blown Java application. Whilst a Java application provides all the resources it needs itself, an applet does not. Normally an applet needs to be included in a web page which is viewed by a Java enabled browser such as Netscape or HotJava because it has no top level window of its own. An alternative is to use the appletviewer program to view the applet.

Linux gives you a further option. if you add the line

        

to a HTML file (and ‘