Tutorial: using Java on MPE/iX

Software

Papers & Training

Java

HP Partners

News & Events

Register for more info

Contents

I. Theoretical Stuff

A. The Java Language

B. The Java Virtual Machine

C. The Java Platform

D. How does Java measure up?

II. Practical Stuff

A. Obtaining Java

B. Installing Java

C. Java Directory Structure

D. Java Components

E. Using Java

F. Where to go for more info

III. Java and Databases

IV. The Java Native Interface

I. Theoretical stuff

I-A. The Java language

Part of the confusion stems from the fact that the term "Java" is used to refer to several distinct parts of a computing platform. In order to make sense of the claims, you need to understand the various pieces and how they relate. We'll look in detail at three key components: The Java programming language, the Java Virtual Machine, and the Java Platform, or Java APIs. Javascript, which you may have heard of or seen also, has absolutely nothing whatsoever to do with any component of Java, and is merely Netscape's attempt to associate their HTML scripting language with Java.

Sun Microsystems, where Java was developed, used the following bit of marketing-speak very early on in Java's life to describe the product's benefits:

Java: A simple, object-oriented, distributed, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, and dynamic language.

There is nothing radically new here; each of these attributes can be applied to one or more languages that were already in existence. But as computing has evolved, the relative importance of these traits has changed: mainframe programmers were much more willing to sacrifice simplicity and portability for performance. Early UNIX implementations demonstrated the willingness to sacrifice virtually everything for the sake of an illusion of portability. The emergence of the World Wide Web, pervasive graphical clients, and advances in software engineering such as object-oriented programming all set the stage for Java, which strikes a balance between all these attributes which meets the requirements of today's distributed computing environments better than any language up to this point.

If you examine the most popular languages in computing history, you'll find that each one had some unique niche where it originally flourished. Languages that never find such a niche are doomed to perish, or become a curiosity. For those that do find a niche, they either grow beyond it and become more widely adopted, or they remain tied to it and fade away when the next wave of computing arrives. Both COBOL are RPG had origins closely tied to Unit Record equipment. COBOL grew beyond its roots, and became the most widely used language for business data processing. RPG code still exists, but its heyday faded with the passing of the keypunch machine. C gained prominence because of its close ties to the UNIX operating system; but the extensive use of UNIX in universities virtually assured the language of a wider use as it became the most widely known language for new entrants into the IT labor pool. Java first gained widespread notoriety because of its inclusion of basic internet functionality - such as URL handling, MIME data types, and Sockets connections - as part of its original basic API set. Java now appears well poised to break away from this niche and become the next widely-adopted language for general purpose computing. The reasons for this leap will be covered in upcoming sections.

We won't cover each of the claims made for Java above, but a few are worth a little more attention:

Java is a truly object-oriented language. For those of you who aren't already believers in the benefits of object-oriented programming styles, object-oriented code is more maintainable, more reusable, and more modular than code written in non-object-oriented fashion. C++ is a hybrid, adding many object-oriented features to C, but not addressing some of that language's heinous shortcomings.

Java is a simple language to use. Automatic garbage collection means that users can have the benefits of dynamically created objects, but without the need to manage memory and worry about proper deallocation. Java provides references to objects, but does not allow these references to be used as pointers in numeric expressions or cast to incorrect types. Java provides numerous sanity-checking features, such as array bounds checking, to help ensure the correctness of programs.

Java provides an inherent portability missing in other languages, by leaving virtually nothing as an implementation-defined detail. Word size and byte order are defined by the language; there are no #pragma or #ifdef constructs to permit programmers to create or use non-portable features.

You should understand that the Java language can be implemented separately from the other Java components. All early implementations of Java compilers created intermediate code that runs on the Java Virtual Machine; but some vendors are today producing compilers that create executable files for a specific architecture.

The Java language continues to evolve. Version 1.0 of the language provided a very clean, simple, and robust implementation of object-oriented concepts. In Version 1.1, the most major change was the introduction of Inner Classes. (see sidebar: Inner Classes and MPE). Java's designers have indicated that parameterized types will most likely be added to the language in a future version. On the other hand, the designers insist they do not plan to add operator overloading, an often requested feature that Java's designers feel is error prone and confusing.

Inner Classes and MPE: When Java introduced the Inner Classes feature in JDK 1.1, it created some problems for the MPE porting effort. Inner Classes are classes, or objects, that are defined inside of another object. The makes it easy to place small helper, or 'adapter', classes in the class they are designed to work with, and is a valuable extension to the original Java Language Specification. However, the implementation of Inner Classes specifies that each Inner Class will be compiled into its own .class file, and that the name of this class file will be the name of the enclosing class, a '$', and the name of the inner class. So if class foo defines an inner class bar, the compiler will place the code for the class in the file foo$bar.class. MPE has never allowed any special characters as part of file names (standard MPE allows only upper case letters and numbers; the POSIX extensions to MPE follow the POSIX .1 standard of also allowing lower case, underscore, hyphen, and dot).

Because inner classes are a key Java feature, patches have been created to allow additional characters (essentially, all printable characters) to be legal for POSIX file names. These patches, MPEJXQ1 and PX2JXQ2, are site specific patches recommended only for those sites using Java. We are currently evaluating making this POSIX extension generally available.

Back to contents

I-B. The Java virtual machine

The Virtual Machine concept is not new. Many compilers, including some of HP's, produce code that is targeted to an abstract 'virtual machine', with a second compilation pass converting this virtual machine code into an architecture-specific executable program. Many of the VM concepts can also be seen in MPE's object code translation technology for Compatibility Mode programs. The Java Virtual Machine has implemented some unique features, however:

The virtual machine was designed specifically to support an object-oriented language. The ability to resolve overloaded method calls, a complex operation, is built directly into the instruction set.

The virtual machine provides bytecode verification capabilities to protect the host system from attack by malicious (or inadvertently harmful) programs.

The virtual machine provides much better performance than a purely interpreted language, because the time-consuming tasks of parsing, checking, and compiling the source code are done before execution. Most of the operations represented by the virtual machine's instruction set can then be executed very quickly at run time.

The bytecode verifier is a complex piece of software that is beyond the scope of this presentation. Briefly, it performs a number of checks on the generated code to ensure that the instruction set is not being used in ways that could cause the virtual machine to behave in ways that might compromise security. (It is not enough for the compiler to enforce these checks, because a hacker could always alter the bytecodes generated by the compiler). Because bytecode verification is an expensive operation, the default behavior is only to verify classes that are loaded from untrusted applications, such as over the Internet. If preferred, a java command line option can force verification of all classes (although Java class files on a local system are no more likely to be harmful than COBOL, C or any other program files, so using this option is somewhat paranoid).

Back to contents

I-C. The Java platform

In Part II, we'll look at each of the Java packages at an appropriate level of detail, so we won't cover many specifics here of what kinds of APIs are available. Instead, we will focus on how this wide set of APIs facilitates portability.

If you take a typical MPE program, and ask how difficult it would be to move it to another platform, you'll usually find that the language is not the most limiting factor. COBOL, C, FORTRAN, and Pascal programs can all be moved to other platforms with a minimum of changes. SPL and Transact programs will be significantly less portable, but then they never claimed otherwise, so anyone choosing to implement in one of these languages did not put portability very high on their list of requirements.

What features other than languages impair program portability? On MPE, it's typically VPLUS, TurboIMAGE, and MPE Intrinsics. Each one of these is an API to provide access to an MPE-specific implementation. Proprietary APIs are used to access proprietary services. In the mainframe and early minicomputer eras, every system was designed this way, and systems would differentiate themselves by the power, performance, and flexibility of these APIs. Many of you may have selected an HP 3000 based on the capabilities provided by the combination of TurboIMAGE, VPLUS, and MPE; in many ways it is still unsurpassed in the strength of its proprietary interfaces.

Then UNIX came along, and changed the rules of the game forever. UNIX offered a far weaker feature set, but the promise of easy portability between systems. Many IT managers found the trade-off worthwhile. And as more and more companies adopted UNIX, the UNIX vendors poured more money into evolving the systems to provide the same rich commercial features as the proprietary platforms. Meanwhile, the proprietary platforms such as MPE realized that the demand for portability must be addressed, and open systems APIs such as POSIX have been added to all the proprietary OSes that survive today.

So pretend for a moment you're on the Java design team, and you have developed this language and virtual machine that you want to become the pervasive computing platform of the next wave of computing. What set of APIs do you build your product on? On the one hand, you have the Windows APIs - representing the largest share of the market, and growing, but not today a real factor in the enterprise systems market. Perhaps a good choice for some companies, but if your paycheck comes from Scott McNealy, this is not going to be a viable option. Another choice is the UNIX APIs. But despite years of standardization attempts, there is no API set you can select that is both sufficiently pervasive and sufficiently powerful to permit the development of the complex, distributed applications you think Java is capable of. The only alternative, you come to realize, is to implement the APIs you need in Java - in essence, do not target Windows platforms, or UNIX platforms, but create a Java platform that can be implemented on top of virtually any operating system. Programs written in the Java language and running in the Java virtual machine are portable largely because this Java Platform is sufficiently robust to keep developers from using any other APIs that would lock them into a single OS platform.

The "100% Pure Java" wars, with Sun and Microsoft as the primary combatants, reveal just what is at stake here. If 100% Pure Java becomes the norm, then every Java developer will in effect be developing software for the HP 3000, along with every other system that implements the Java Platform (language, VM, and APIs). There could be a resulting flood of new applications greater than any we have seen in MPE's history. The term "legacy system" will no longer apply to entire operating systems, but merely to specific applications which no longer meet your needs.

On the other hand, if Microsoft wins, then they will have succeeded in fragmenting the Java marketplace just as the UNIX marketplace was fragmented by various incompatible flavors of UNIX. There will be some winners - Microsoft among them, and some losers - including MPE. Also losing will be any company that wants a healthy competition in the operating system and hardware marketplaces.

I am a strong advocate of the "100% Pure Java" initiative, and at the same time, I've been working to develop a TurboIMAGE class library that makes use of the non-portable Java Native Interface. I don't think this is inconsistent; TurboIMAGE is obviously an MPE-specific technology. Writing a TurboIMAGE class library that can be ported to other platforms provides no benefit unless TurboIMAGE itself is ported to those platforms. However, there are portable database interfaces available - most notably, the Java Database Connectivity, or JDBC, package from JavaSoft. Implementing a JDBC interface for TurboIMAGE would provide a portable interface to TurboIMAGE databases. Programs written on the HP 3000 that use JDBC to access TurboIMAGE can be ported to other platforms, and use the same JDBC interfaces to access Oracle, Informix, or whatever other databases are present on that platform. By the same token, all the applications being written on other platforms that use JDBC to access the various relational database engines can be ported to the HP 3000, and be used without modification to access TurboIMAGE databases.

Given this, if I were an application developer and could support only one database interface, I would pick JDBC without question. A better solution might be to support multiple interfaces - JDBC for portability, direct TurboIMAGE access for the best performance on MPE/iX. Is this worth the additional effort? Without either one of these technologies available for performance testing, it's impossible to say. If I were designing an application today, I would definitely layer my software so that database access was isolated, making it easy at some future point to change to a different database access technology. (I would also do the same with any User Interface code, as the AWT has been the most volatile of the APIs, and is likely to change again in future releases).

Back to contents

I-D. So how does 'Java' measure up to the claims?

I-D-1. Java performance

For typical OLTP applications, where much of the execution time is consumed by database API's or other functions not provided by the application programmer, the application may not be very sensitive to the performance of the language used. Only if a significant amount of time is spent executing the user-written code will the implementation language make a noticeable impact.

There are a number of techniques for improving Java performance. A native compiler that produces object code directly for the target platform should be able to produce Java program files just as fast as any other natively compiled language, but at the cost of loss of portability. An interesting compromise is provided through a technique known as just-in-time compilation. With a just-in-time compiler, the javac compiler still produces bytecodes for the Java virtual machine, but these bytecodes are then converted to native instructions at run-time on a method-by-method basis as each method is called. HP's just-in-time compiler provides a fourteenfold improvement over the interpreted Java Virtual Machine when running the popular CaffeineMark benchmark tests. The just-in-time compiler is a standard part of HP's Java offering for both MPE/iX and HP-UX.

Sun is also providing improved performance between releases; a number of performance enhancements were made to the 1.1 release, and even more are scheduled for the 1.2 version due late this summer.

In short, Java performance stacks up very well against interpreted languages. Against compiled languages, a Just-in-time compiler can narrow the performance gap to what would be considered an acceptable range for most applications. Java performance will continue to improve, and processing power will continue to become less expensive, so that there are very few applications for which Java's performance would be considered unacceptable.

I-D-2. Java security

Much of Java's security is in fact security enforced on Applets. Applets are Java applications that are intended to run inside of another 'host' program, which is usually a web browser. Applets are usually transferred via a network to run on a system other than the one on which they are stored; in many if not most cases, the system executing the applet does not want to assume that the site providing the applet is a trusted source. Therefore, Java imposes a number of restrictions on Applets, such as:

They cannot access the local file system on the system where they are executed.
They cannot make network connections to any system other than the one from which they were downloaded.
It is important to note that these restrictions are applied only to applets; not to applications: if they were applied universally, it would be impossible to write almost any type of business application with Java.

Other Java security capabilities include the bytecode verification technology discussed earlier.

Java's security model seems to be pretty robust. There have been a few well-publicized holes, which have been fixed, and there could very well still be vulnerability somewhere. However, given the state of computer security in general, it does not seem that a computer with Java on it will be inherently less safe than a computer without Java. With or without Java, it is only sensible to exercise some degree of caution in downloading software from completely unknown sources. Also, note that all Java security flaws have been due to implementation bugs, and not due to design deficiencies. Contrast this to ActiveX, which has a fundamentally unsecure design which cannot be corrected through an improved implementation.

I-D-3. Java portability

One area where Java has received some criticism is in the AWT look and feel. Although a particular application may in fact run on a PC, a UNIX Workstation, and a Macintosh, the implementation of the AWT on those platforms may cause variations in look and feel. If you talk to end users, I think you'll find that this is exactly what they want: the application running on a PC should conform to the standard Windows application look and feel wherever possible. However, some developers have expressed disgust over Java's inability to make all these platforms indistinguishable from one another. Go figure.

Another area where differences may show up between Java implementations is in the scheduling of threads. The Java specification leaves some latitude to the developer in how Threads of equal priority are handled. When thread priorities differ, the highest priority thread must always run. But if priorities are equal, the runtime may run one thread until it finishes or blocks, or it may implement some sort of timeslicing between the equal priority threads. The number of applications that are dependent on a specific scheduling behavior is very small (and well written Java programs should not be dependent on this implementation detail).

In each of these areas - performance, portability, and security - there is something behind the complaints of the Java-bashers. But given the alternatives - such as the portability of UNIX software, or the security of ActiveX -- Java seems to be worth consideration.

Back to contents

II. Practical stuff

II-A. Obtaining Java

Other distribution methods are the FTP server provided by 3K associates (look in the POSIX subdirectory) and the INTEREX freeware tape, compiled by Michael Hensley of Allegro Consultants and distributed by the INTEREX User's Group.

Java Versions: The various components that comprise Java are released as part of a package called the Java Developer's Kit, or JDK. The first JDK ported to MPE/iX was version 1.0.1, which was released in late 1996. In the second quarter of 1997, we released JDK 1.1 for MPE/iX to a small number of beta sites. At the time of this writing (June 97), we have released a preliminary JDK 1.1.2, and are working on porting the final JDK 1.1.2. There is also a JDK 1.1.3 currently in beta, and JavaSoft has announced a late summer availability for JDK 1.2.

Java for MPE/iX requires that you be running MPE/iX Release 5.0, with patch MPEHX70, or any version of MPE/iX 5.5. Java will also be ready to run on MPE/iX 6.0 when that OS version is released. If you have any 1.0-based version of Java, it is strongly recommended that you update to a 1.1-based version; no further bug fixes or enhancements are being made to the 1.0 releases. You will probably want to obtain and install patches MPEJXQ1 and PX2JXQ2, as mentioned in the 'Inner Classes and MPE' box earlier in the paper, to allow you to develop and execute Java code that uses the inner classes feature of Java.

Back to contents

II-B. Installing Java

The 5.5 tarfile or 5.0 mover file needs to be installed on the target system, using whatever transport method you prefer (MPE :STORE, FTP, Reflection file transfer, etc.) All files in the archive are stored in absolute pathname format, so it does not matter where you place the distribution file before installing. The file must first be unzipped using the gunzip utility, as shown:

shell/iX> gunzip TARFILE

gunzip TRUCK

After unzipping, Java is installed by either:

shell/iX> tar -xovf TARFILE
or
shell/iX> mover -x TRUCK

Shell or CI?

Java can be run either from the MPE Command Interpreter or from the POSIX shell. There are a few differences between the two environments:

The MPE Command Interpreter will launch Java programs faster, due to 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 have to provide values in most cases.
There are five environment variables which can be used by Java, and you can make Java easier to use by providing values for these via a command file or UDC (if you use Java from the MPE CI) or a shell script or .profile (if you use Java from the POSIX shell). These variables and their typical settings are:

export SYSNAME=hp3000		 

export PATH=$PATH:/usr/local/java/latest/bin 
setenv HPPATH "!hppath,/usr/local/java/latest/lib/PA-RISC/green_threads"

export CLASSPATH=$CLASSPATH:(add your stuff here)
setenv CLASSPATH "/usr/local/java/latest/lib/classes.zip:(add your stuff here)"

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:(add your stuff here)
setenv LD_LIBRARY_PATH "/usr/local/java/latest/lib/PA-RISC/green_threads:
(add your stuff here)"

export THREADS_FLAG=green

export DISPLAY=sysname:0.0
setenv DISPLAY "sysname:0.0"

Back to contents

II-C. Java directory structure

The next level down specifies the Java version. For example, version 1.1.2 of Java is installed under /usr/local/java/jdk1.1.2. We recommend that you create a symbolic link called 'latest' that can be used to access the most recent version of Java, so that shell scripts, jobstreams, and command files do not need to be changed every time a new version of Java is installed. This can be done as:

shell/iX> ln -s /usr/local/java/jdk1.1.2 /usr/local/java/latest
or
:NEWLINK /usr/local/java/latest, /usr/local/java/jdk1.1.2

Under /usr/local/java/latest are two major hierarchies: lib and bin; the optional hierarchies demo and doc, and a number of files, such as the latest README file.

The bin hierarchy contains Java program files, and shell scripts used to run those programs. Under /usr/local/java/latest/bin are shell scripts used to run each of the Java components (which will be described in the following section). So for example, /usr/local/java/latest/java is the script to run the latest version of the Java interpreter. If the PATH (or HPPATH) variable is correctly set, is not necessary to specify this entire path; 'java MyClass' would be sufficient.

The actual program binaries are two levels further down in the hierarchy. Under /usr/local/java/latest/bin is the directory PA-RISC. If MPE were ever ported to a hardware architecture other than PA-RISC, additional directories could be created at this level to hold the platform-specific binaries. Under the PA-RISC directory is the directory green_threads. This directory holds the actual Java programs, Green threads is a simulated threads library provided by JavaSoft. If we choose at some point to create a version of Java that uses MPE's kernel threads, a native_threads subdirectory would be created at this level to hold that version of the binaries.

The lib hierarchy follows the same structure as the bin hierarchy, with PA-RISCC and green_threads subdirectories. There is one file that resides at the top level of the lib hierarchy: classes.zip. This is an archive file containing all of the standard Java classes. It does not need to be unzipped to be accessed (and in fact, can be accessed faster as a single zip file than as hundreds of individual disk files). At the bottom level of the hierarchy are a number of specialized libraries that are dynamically loaded when needed for certain Java tasks; for example, libnet.sl contains the Java networking code, and libawt.sl contains code used by the Abstract Windowing Toolkit.

The demo directory holds a number of demo programs.

The doc directory holds HTML format API documentation.

Back to contents

II-D. Java components

II-D-1. Programs

java: The optimized version of the Java interpreter
java_g The debugging version of the Java interpreter
javah - The Java header file generator
javap - The Java class file disassember

II-D-2. Shell scripts

Several Java programs and utilities are really just classes that get executed by the Java Virtual Machine. For example, each of the following 'programs' can actually be run by passing the name of the appropriate class to Java:

To run		You can type			Or:
javac		javac foo.java		java sun.tools.javac.Main foo.java
appletviewer	appletviewer foo.html	java sun.applet.AppletViewer foo.html
javadoc	javadoc foo.class		java sun.tools.javadoc.Main foo.class

appletviewer - this utility can act as a stand-in for a web browser to allow testing of Applets. It is especially useful if your HP 3000 is not a web server, but you want to develop and test Java applets on the HP 3000.

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

javac HelloWorld.java

java HelloWorld

	private native void DBOPEN(byte base[], String pass, 
				short mode, DBStatus status);

	static {
		System.loadLibrary("TurboIMAGE");
	}

package TurboIMAGE;

/** This class is used to represent a TurboIMAGE database.
 *
 * @version X.00.10, for JDK 1.1, April 1997
 * @author  Mike Yawn
 */
public class Database {

   // Intrinsic Parameters
   byte[]   basename = new byte[26];
   String   password = new String(";");
   String   dummy    = new String(" ");  // an ignored parameter
   DBStatus status = new DBStatus();

   static {
      // Note actual library name is libTurboIMAGE[_g].sl
      System.loadLibrary("TurboIMAGE");
   }

   /** Constructor to create database object, given a
    *  local database root file name.  If the first two
    *  characters you pass are not blanks, this routine
    *  will add blanks to the beginning of the name.  If
    *  the last character is not a semicolon, this routine
    *  will add one.  Filename should be in MPE syntax.
    * @param dbRootFile The name of the database root file.
    */
   public Database(String dbRootFile){
      int endchar = dbRootFile.length();
      if (dbRootFile.startsWith("  ")){
	basename = dbRootFile.getBytes();
      } else {
             basename[0] = ' '; basename[1] = ' ';
             for (int i=0; i<endchar; i++) {
                 basename[i+2] = (byte) dbRootFile.charAt(i);
             }
             endchar += 2;
      }
      if((basename[endchar-1] != ';') && (basename[endchar-1] != ' ')) {
         basename[endchar]= ';'; 
      }
   }

   /** Set the database password.  Will add trailing semicolon
     * if not specified by the user.  If this method is not
     * called prior to an open call, the creator password will
     * be used as a default */
   public void setPassword(String pass){
      if(pass.endsWith(";")) {
         password = new String(pass);
      } else {
        password = new String(pass + ";");
      }
   }

   /** Open the database with explicit mode.
    *  Numeric mode parameters will be more familiar to long-time
    *  users of the TurboIMAGE intrinsic calls.  Additional calls
    *  are available that use mnemonics to describe the open mode,
    *  which is more self-documenting.
    * 
    * @param mode   16-bit numeric value for open mode
    */
   public void open(short mode) throws IMAGEException {
      DBOPEN(basename, password, mode, status);
   }

   // Stubs that call TurboIMAGE Intrinsics
   private native void DBOPEN(byte base[], String pass, short mode,
                              DBStatus status);

// main method allows this class to be tested independently.  In actual
// usage, this class' main method is never executed.
public static void main(String[] argv) {
    Database testdb;
    String   testname;
    String   testpass;
    Byte     modein;
    Short    testmode;

    java.io.DataInputStream ins = new java.io.DataInputStream(System.in);
    try {
       System.out.print("Enter database name :");
       testname = ins.readLine();
       System.out.print("Enter password      :");
       testpass = ins.readLine();;
       System.out.print("Enter mode          :");
       testmode = new Short(ins.readLine());
         // above may throw NumberFormatException
       testdb   = new Database(testname);
       testdb.setPassword(testpass);
       testdb.open(testmode.shortValue());
       System.out.println("now open: " + testname);
    } catch (Exception e) {
        System.out.println("Database main: " + e);
    }
}

}

javah -jni TurboIMAGE.Database

	/* DO NOT EDIT THIS FILE - it is machine generated */
	#include <jni.h>
	/* Header for class TurboIMAGE_Database */
	
 	#ifndef _Included_TurboIMAGE_Database
	#define _Included_TurboIMAGE_Database
	#ifdef __cplusplus
	extern "C"
	#endif
	/*
  	 * Class:	TurboIMAGE_Database
	 * Method:	DBOPEN
	 * Signature:	([BLjava/lang/String;SLTurboIMAGE/DBStatus;)V
	 */
	JNIEXPORT void JNICALL Java_TurboIMAGE_Database_DBOPEN
	   (JNIEnv *, jobject, jbyteArray, jstring, jshort, jobject);

	#ifdef __cplusplus
	}
	#endif
	#endif

#include "TurboIMAGE.h"                    
/* function to throw exceptions based on TurboIMAGE errors */                   
void ThrowException(JNIEnv *env, char * intrinsic, void *CStatus)
{          
	char message[100];                                               
	short msglen;                                                       
	jclass IEClass;

	/* first report & clear any pending exception */ 
	(*env)->ExceptionDescribe(env);  
	 (*env)->ExceptionClear(env);                    
	/* now see what our problem is */  
	dberror(CStatus, message, &msglen); 
	message[msglen] = '\0'; /* needs null terminator */ 
	/* and throw an exception to report it */ 
	IEClass=(*env)->FindClass(env, "TurboIMAGE/IMAGEException"); 
	(*env)->ThrowNew(env, IEClass, message);                     
} 

//**********************************************************
//********** TurboIMAGE Database Implementation ************
//**********************************************************
/* Function to call DBOPEN */ 
JNIEXPORT void JNICALL
Java_TurboIMAGE_Database_DBOPEN(JNIEnv    *env,
		                jobject    this, 
		                jbyteArray j_basename,
		                jstring    j_password,
		                jshort     j_mode,
		                jobject    j_status) { 
	
	 int i;

	// JNI types for accessing DBStatus 
	jfieldID         f_halfword;
 	jobject          p_halfword; 
	jshort          *a_halfword;  
	jclass           c_DBStatus; 
                                                                      
	 // Get JNI fields into C types  
	jbyte *base = (*env)->GetByteArrayElements(env, j_basename, 0); 
 	const char *pass = (*env)->GetStringUTFChars(env, j_password, 0); 

	c_DBStatus = (*env)->GetObjectClass(env, j_status);  
	f_halfword = (*env)->GetFieldID(env, c_DBStatus, 
	                                     "halfword", "[S"); 
	p_halfword = (*env)->GetObjectField(env, j_status, f_halfword); 
	a_halfword = (*env)->GetShortArrayElements(env, p_halfword, 0);  

	dbopen(base, pass, &j_mode, a_halfword);

        if (a_halfword[0] < 0){
		ThrowException(env, "DBOPEN", a_halfword); 
		return; 
	} 
	
        (*env)->ReleaseByteArrayElements(env, j_basename, base, 0); 
	(*env)->ReleaseStringUTFChars(env, j_password, pass);            
	(*env)->ReleaseShortArrayElements(env, p_halfword, a_halfword, 0);
} 

shell/iX> gcc -I/usr/local/java/latest/include 
          -I/usr/local/java/latest/include/mpe 
          -c -o DatabaseImpl.o DatabaseImpl.c

shell/iX> callci linkedit
LinkEdit> buildxl ./libTurboIMAGE.sl;limit=10
LinkEdit> addxl ./DatabaseImpl.o ./libTurboIMAGE.sl

LinkEdit> exit

shell/iX> java Database