Novell is now a part of Micro Focus

The Java Development Kit for NetWare

Articles and Tips: article

KRIS MAGNUSSON
Software Engineer
NetWare SDK

QUINN JENSEN
Software Engineer
Java Team

01 Nov 1996


Describes the newly released Novell Software Development Kit for the Java Platform (NJDK). Includes information on the Abstract Windowing Toolkit (AWT), how to install the NJDK on your server, and how to launch Java applications.

Introduction

On 16 October 1996, the Java for NetWare team delivered the Alpha Refresh of the Novell Software Development Kit for the Java Platform (NJDK). The NJDK contains the Java runtime environment that can display AWT-enabled applications directly on the server. The AWT supports high-end video cards and serial and PS/2 mouses through the AIO interface, making the server an effective platform for running local Java applications.

The Alpha Refresh provides the runtime and distributed execution infrastructure for Java, but doesn't provide NetWare class extensions or tools beyond what Sun provides in the Java Development Kit (JDK). The NJDK only runs on NetWare 4.1x with Green River Modular CLIB. The NJDK does not run on NetWare 3.x servers.

The NJDK includes the runtime environment, and the AWT, and an appletviewer. Previously, licensing issues have prevented Novell from releasing javac and javadoc, so developers had to write Java code on a development platform. However, Novell has released these tools running on NetWare, so you can edit, compile, run, and document code directly on the server as a convenience.

Installing Java on the Server

To install the NJDK on the server, you must load support for long names onto your server. We recommend adding long name support to your STARTUP.NCF file. Long file name support differs between server versions, so consult your System Administration documentation for the correct command for your server.

Once support for long filenames is loaded, download the self-extracting archive that contains the NJDK, available at http://www.novell.com/java. Once you download the archive, execute it in the volume in which you want to install the NJDK, typically SYS. This will unpack the archive and create the appropriate directories for the NJDK.

Next, add Java directories to your SEARCH variable, edit the Java GUI's configuration file to reflect the type of mouse attached to your server, and then edit STARTUP.NCF to load the mouse driver at server startup.

The last step is to run the SuperProbe configuration utility, an NCF that configures the Java GUI for your server's video hardware. This utility could fail if your server uses unsupported video hardware. However, one known workaround is to change the video driver that SuperProbe chose to the generic 16-color VGA or SVGA driver. If this doesn't work, you may need to install a supported video card in your server. Video cards using the 32- or 64-bit S3 chipsets generally work well.

Running a Java program

In the Alpha Refresh, starting a Java application or applet means first loading the JVM if it isn't already loaded. Do this by typing

load java

on the system console. After loading the JVM, you start the GUI by typing

startx

Once the GUI is loaded, launch a GUI-enabled Java application by typing

java <application<

or

applet <path to HTML file<

To start a Java application or applet , the server command processor intercepts commands that start with "java" and "applet." Each time you start an application from the command line, a new JVM is started.

Java Applications and Applets

Nearly all Java applications run on the NetWare server, including HotJava. Porting Java applications to NetWare can be as easy as copying bytecode from a web site into your classpath, though porting applications that rely on native methods requires more work. Be aware that running Java applications that use the GUI on the server degrades server performance. Applets on NetWare run in the ported Appletviewer with the standard security restrictions.

Java and Modular CLIB

Modular CLIB is still the published API for NetWare-Java complements the NLM-based kernel development environment but doesn't replace it. NetWare developers whose applications require top performance should use NLMs.

Mixing Java and C

Programmers can combine the functionality of NLMs with Java applications through Java's support for native methods. However, maintaining platform independence requires that you don't use Novell-specific APIs, since many of them are not available on other Java platforms.

JVM Implementation for NetWare

Java for NetWare supports multiple, isolated JVMs running at the same time on the same platform. Each Java application runs in its own JVM. Java for NetWare supports multiple data segments with one shared code area and one shared data area. Java uses the 4.11 (Green River) CLIB, which is fully compatible with 4.10.

Loading JAVA.NLM. When you load JAVA.NLM, the core OS assigns Java applications two areas of memory-the code area and the data area. The code area contains the byte code of Java applications that you execute on the server. This byte code is assigned another memory area for storing data associated with a Java application. The data area has two parts-the constant data area and the variable data area. The constant data area contains shared data that remains in a constant memory location.

Data stored in this location includes global information about Java on the server, such as all the running JVMs and other shared constants. The variable data area contains data used by Java applications. JAVA.NLM registers the "java" and "applet" commands with the command line process. It creates an initial dummy JVM, initializes the heap and global data, sets up NetWare page fault handling, and fixes up pointers between the code area and the relocated data area.

Launching Java applications. The stage is set for launching Java applications. When you launch a Java application, Java assigns to it a new variable data area, using the original variable data area as a template. The way Java keeps track of the variable data assigned to the Java byte code is through a page table managed by Java. When you launch an application, the new JVM associated with it is assigned an entry in the Java page table. This page table maintains a valid pointer to the data associated with the application in the variable data area. This mechanism is what allows multiple Java applications to run concurrently; each think they have the area 0xF0000000, but the page table allows Java to juggle the data of each JVM.

When the core OS switches to the thread of a Java application executing in its own virtual machine, Java shoves its own page table into the core OS. The OS thus hands off control of Java application threads to Java itself. JVM memory requirements are high, though not higher than on other platforms. Executing a simple "Hello, World!" application requires 172 KB for the minimum number of threads a JVM can use, which is three. Heap used for objects requires 69 KB, and various small memory allocations require 147 KB. Despite these requirements, Java applications run faster on NetWare than on other platforms-all byte code is kept in memory, and the absence of a demand-paged virtual memory system speeds up application execution.

NetWare-Dependent Class Implementations Certain Java classes and methods have NetWare-specific implementations. For example, process class and NetWare process extensions, as well the following runtime methods, are specific to NetWare: exec(),freeMemory(),exit(),load(),loadLibrary(), getProperty(),Redirection

The Abstract Windowing Toolkit

The AWT coexists with other NetWare console applications as a normal NetWare screen. Developers and administrators can toggle between multiple screens using the familiar <Alt<<Esc< key command.

Peer Model

All Java-compliant runtimes require a port of the Abstract Windowing Toolkit (AWT) to display graphical user interfaces of Java applications and applets. JavaSoft designed the AWT to abstract the features of native GUIs into a set of methods specific to AWT objects. Doing this required that AWT objects map to their native peers on a specific operating environment.

Creating a fully Java-compliant environment on NetWare requires a native GUI. However, since the NetWare server is a text-based environment, and since running AWT-enabled applications and applets on the NetWare server was a requirement, the Java for NetWare team had to choose a native model. We chose an implementation of TinyAWT based on XFree86, a common X Window System display model. The X Window System API is not exposed-Java is the only gateway to displaying GUIs on the server.

Video Drivers

AWT on NetWare uses ports of the Xfree86 video drivers. Novell contracted with a third party to write drivers for common video cards based on standard VGA, SVGA, Cirrus Logic, S3, and ATI mach32 and mach64 chipsets.

Remotable GUIs

AWT on NetWare depends on the standard XFree86 mechanisms for displaying graphics. Because XFree86 uses the X Window System, Java GUIs are remotable and can be displayed on any client with an X Window System.

Java Dependencies on the Core OS

The Java runtime's dependencies on the core OS requires Green River's enhancements to the core OS.

Registrable Exception Handlers for all Hardware Exceptions . Arithmetic and memory faults are architecturally visible to the Java environment. For 4.1x compatibility, Java for NetWare uses memory fault recovery procedures.

Large Heap Support. The JVM uses a growable memory heap that is logically contiguous and grows both up and down. The JVM starts up by reserving a large hole or extent in logical memory-its size is configurable at runtime, and is set based on the Java application's needs. Real pages are mapped in and freed as needed. To avoid excessive [TLB] flushing, the logical memory holes allocated by multiple JVMs are placed at unique logical addresses, so long as logical space is available.

Future Enhancements

Future enhancements will provide greater stability, flexibility, and performance for the Java runtime and for executables.

Preemption. Preemption is scheduled to be added to the core OS in the IntranetWare III time frame. When this takes place, events raised into the JVM can suspend the current Java thread and resume another. The OS will be able to periodically bump, but not kill, hung or compute-bound threads.

Updated GUI Configuration. Often the hardest part of running the GUI on the server is configuring the video card correctly, and currently the utilities provided for configuring the GUI are primitive and under certain circumstance require that you hand-edit the Xfree86 configuration files. To mitigate configuration woes, future plans include a GUI configuration utility.

Just-in-time (JIT) Compilers. The Java for NetWare team has completed ports of several JIT compilers to NetWare, but for licensing reasons, none are currently included in the Alpha Refresh. Future releases will include JITs that will substantially increase execution performance.

Protected Memory. Each Java virtual machine will be able to run in separate memory spaces with code sharing and protection against JVM faults and native method faults, with registrable handlers.

Symmetric Multiprocessing (SMP). SMP neither helps nor hinders Java applications. Eventually, the Java runtime will take advantage of SMP.

Java Virtual Machines Running in Ring 3. One future goal for both interpreted and compiled Java code is to run Java virtual machines in Ring 3.

Demand-paged Virtual Memory. Future JVMs will use demand-paged virtual memory, swapping, and automatically growing stacks.

Internationalization. JavaSoft will address internationalization in the upcoming JDK 1.1 release; their stated intention is to allow developers to internationalize UI strings and system messages. Future NJDKs based on JDK 1.1 will allow full internationalization of UIs and messages.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates