Developer's Kit for Java/iX

• This first release of Java/iX will be supported by the Response Center on a "best effort" basis.

• Performance has been a secondary concern to reliability in our engineering efforts up to this point. While Java/iX includes HP's own Just-In-Time (JIT) compiler which allows Java programs to be converted into native PA-RISC code at runtime, customers may find that the overall performance for some Java applications will be less at this time than on other platforms.

• This release of Java/iX does not pass 100% of the Java Compatibility Kit test suite, which prevents it from being officially labeled as 'Java Compatible' at this time.

• Sun is developing a functionality specification for Java running on server systems such as the HP 3000. It is likely that we will target this specification for the functionality to be included in future releases of Java/iX. Thus it is possible that some of the Java APIs which are not normally used in server-side Java programs, but which are included in the current Java/iX release, may not be supported in future versions.

If you have not downloaded and installed any version of Java from the JAZZ web server or an Interex freeware tape, then you can safely install the version of Java included with this release of MPE/iX. If you have installed another version of Java, you should check to see whether the one included with the OS is more recent. If you have installed any version of Java on your system, you can determine the version by typing the following at the POSIX shell prompt (or at a CI prompt if you have set up the proper UDCs to allow Java to be accessed from the Command Interpreter):

java -version

You can compare this to the version number in the readme file (README.INSTALL.JAVA) after updating your MPE/iX system to 6.0. If the 6.0 version is more recent, you can install it by typing the following at the MPE CI prompt:

:STREAM JINSTJDK.INSTALL.JAVA

• The MPE Command Interpreter will launch Java programs faster, because of the efficiency of MPE's CREATEPROCESS mechanism compared to POSIX fork() and exec().

• The POSIX shell provides intelligent default values for several environment variables, so the user does not, in most cases, have to provide values.

• SYSNAME

• PATH (or HPPATH)

• CLASSPATH

• LD_LIBRARY_PATH

• THREADS_FLAG

• DISPLAY

Example of setting SYSNAME from the shell:

shell/iX> export SYSNAME=hp3000

The SYSNAME variable is tested by some of the shell scripts provided with Java. It does not need to be set in the MPE CI environment, since the Java shell scripts are not used when running from the CI. It must be set to hp3000, exactly as shown above.

Example of setting PATH from the shell:

shell/iX> export PATH=$PATH:/usr/local/java/latest/bin

Example of setting HPPATH from the CI:

:setvar HPPATH HPPATH+",/usr/local/java/latest/bin/PA-RISC/green_threads"

These variables are not Java-specific, but rather the standard path variables used to search for executable program files. The Java executable program files are in the directory shown for the HPPATH variable. When executing Java from the CI, the actual program binary files are executed. When executing Java from the shell, we do not execute the Java program files directly, but instead execute shell "wrapper" scripts that are in the directory indicated by the PATH statement above. These shell scripts set standard env variables for us (such as CLASSPATH and LD_LIBRARY_PATH, shown below), so that we don't need to specify values for these unless we wish to add to or replace the standard settings.

Example of setting CLASSPATH from the shell:

shell/iX> export CLASSPATH=$CLASSPATH:(add your stuff here)

Example of setting CLASSPATH from the CI:

:setvar CLASSPATH "/usr/local/java/latest/lib/classes.zip:(add your stuff here)"

Like the PATH variable, the CLASSPATH variable is a colon-separated list of directories (or zipped archive files) to search. While the PATH and HPPATH variables list the directories to search for program files, the CLASSPATH variable lists the directories to search for Java classes.

The standard Java classes (such as those that make up the java.lang, java.io, and java.net packages) are all bundled together in a single ZIP format archive file, called classes.zip and stored at the location shown in the :SETVAR command above. When running from the shell, the wrapper script sets the CLASSPATH for you to include this file; when running from the CI, you must create a CLASSPATH variable to include the classes.zip file. In either case, any additional classes, such as application or applet-specific classes you have written or obtained from a third party, must also be listed in the CLASSPATH. Because locations on the CLASSPATH are searched in the order you specify, best performance is obtained when you order the directories on the CLASSPATH so that the directories containing the most frequently-accessed classes are listed first. (In most cases, this means that the standard classes.zip file should come before any others).

Example of setting LD_LIBRARY_PATH from the shell:

shell/iX> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:(add your stuff here)

Example of setting LD_LIBRARY_PATH from the CI:

:setvar LD_LIBRARY_PATH "/usr/local/java/latest/lib/PA-RISC/green_threads:
(add your stuff here)"

Again, we specify a colon-separated list of directories to search. In this case, we're providing the locations to search for library (XL) files that contain native (that is, platform-specific) code. The java classes—all the files that go into classes.zip—are the same on all platforms. The platform-specific code is written in C, and compiled into shared libraries (XLs on MPE). The standard Java runtime libraries are in the location shown on the MPE :SETVAR command above; the Java shell wrappers will include this location automatically when running Java from the shell. Users usually do not need to add additional locations to this variable; it is used only if you have written (or obtained from a third party) Java code that includes native (non-portable) code. One example of such a library is the TurboIMAGE/XL class library for MPE, which includes an XL that has the interfaces to the IMAGE/SQL intrinsics.

Example of setting from the shell:

shell/iX> export THREADS_FLAG=green

The THREADS_FLAG variable is only needed when running from the shell, and tells the java shell wrappers to use the binaries found in the green_threads subdirectory (when running from the CI, we've already indicated this in our setting of the HPPATH variable). There are two possible ways to implement multithreading when porting Java to a new platform: using kernel threads (with binaries in the native_threads directory) or using library threads (with binaries in the green_threads directory). The current MPE implementation uses green_threads, although a native_threads version may be developed in the future. If so, the THREADS_FLAG variable could be set to native to select the kernel threads implementation (and the HPPATH variable would be changed for CI users to select the native_threads directory).

Example of setting from the shell:

shell/iX> export DISPLAY=sysname:0

Example of setting from the CI:

:setvar DISPLAY "sysname:0"

The DISPLAY value is used by the AWT and Applet classes to locate the display device. Only X-Windows compatible display devices (UNIX workstations, X-terminals, or PCs running X-Windows emulation software) are supported for the display device. Most HP 3000 Java users probably won't need the AWT on the HP 3000; user-interface code is usually downloaded to a Web browser or run in some other client-server type of configuration. We certainly recommend this for your own development:

You may, however, encounter Java applications that aren't designed this way, and the MPE AWT implementation will allow you to execute these applications, if you can provide an X-Windows capable display device accessible from the HP 3000.

There are no unique tools on the HP 3000 for writing Java programs; you just select your favorite word processor and enter the program text. You can use either a traditional HP 3000 editor such as EDIT/3000 or HP EDIT, or you can use the vi editor from within the POSIX shell. The naming of a Java source file should follow the following conventions:

Because of these requirements, if you use an editor that does not support full POSIX naming conventions, you must either use file equations or rename your source file to meet the requirements.

If your program is part of a package, it needs to be placed in an HFS directory whose name is the same as the package name.

For an example, consider the following, perhaps the simplest possible Java program:

public class HelloWorld
{
    public static void main(String[] args) {
         System.out.println("Hello, World!");
         }
}

Because the class name is HelloWorld, this program needs to be saved as HelloWorld.java.

The compiler for Java programs is called javac, so the above program is compiled simply by:

javac HelloWorld.java

This command can be entered at either a CI prompt or at a shell prompt. The compiler will produce a class file called HelloWorld.class.

To run the above program, type at either the CI or shell prompt:

java HelloWorld

Note that the .class extension isn't needed (and will cause an error if specified).

• The Official JavaSoft home page http://java.sun.com is updated very frequently. Check here for new releases of add-on products, such as the Beans Development Kit (BDK), Java Workshop, or Java Web Server. On-line tutorials and reference documents are available, plus access to developer resources and a wealth of other information.

• The Home Page for Java on the HP 3000 http://jazz.external.hp.com/src/java contains the latest MPE-specific Java information and downloadable software.