Re: Java on the AS/400

Excerpts from midrange-l: 31-May-98 Re: Java on the AS/400 Chris
Rehm@ibm.net (3028) 

> In the case of IBM, they have developed a set of classes for accessing AS/400 
> "native methods." 

I'm know I'm nit-picking, and I know what you meant, but this
terminology isn't quite right...  In Java, the term 'native method' has
a very specific meaning--a native method is a Java method implemented in
a language other than Java.  While the AS/400 Toolbox for Java does
provide  access to AS/400-specific items ('native *functions*', if you
will), this is not the same thing as 'native methods.' 

For JDK 1.1, Sun published the Java Native Interface (JNI)
specification, which is available for download at
http://java.sun.com/products/jdk/1.1/download-pdf-ps.html.  This
specification, which describes the JNI functions, tacitly assumes 'C' or
'C++' as the 'other language,' though any language with a thread-safe
runtime environment and the necessary 'extern' language constructs (e.g.
an 'extern' array of function pointers) should be usable.  FWIW, there's
also a 'tutorial' on native methods at
http://java.sun.com/docs/books/tutorial/native1.1/index.html -- good
stuff. 

Incidentally, native methods are used heavily by the Java portions of
the JVM code itself, as you can imagine.  Tasks such as opening and
assigning file descriptors to System.in, System.out and System.err are
inherently platform-specific, and are done by the JVM code using native
methods. 

>From the materials I've read, there are only three reasons to ever use
Java native methods in an applications context:  
    1) to leverage existing code libraries, instead of re-writing
    them in Java,  
    2) to access platform-specific function not available to pure
    Java, and  
    3) to implement extremely performance-sensitive methods. 

The motivation behind reason 2 is exactly the motivation that gave rise
to the AS/400 Toolbox for Java.  Without the Toolbox, all Java
programmers on the AS/400 might be compelled to use native methods to
try to craft their own classes for such things as Data Queues, Security
functions, Record level I/O, etc.  Recognizing this inevitability, IBM
stepped up to providing this implementation themselves, and saved the
AS/400 Java application programmers a lot of error-prone, complicated,
and possibly redundant effort. 

Of course, reason 1 and 2 are sort of two sides of the same coin...  and
hopefully our 'direct execution' model will reduce or eliminate the
relative importance of reason 3.  This would leave zero good reasons for
a Java application programmer to write 'native methods' on the AS/400
system.   

That'd be great, because native methods on the AS/400 are somewhat
dodgy, particularly in the National Language arena...  The JNI expects
all input as UTF-8, which requires some C coding wrinkles (#pragma
convert, iconv(), etc.) that makeup just won't hide.  Also, the late
arrival of the 'long long' 8-byte integer to C has complicated the
support for the Java 'jlong' in native methods, as well. 

Anyway, just my 2 cents worth.  I saw the phrase 'native method' and
went berserk.  <G>  (Actually, that first happened a couple of years
ago, when I was asked to implement the JNI on the AS/400 -- it's been
chronic berserkosity since then.) 

-blair 

  ___   _           Blair Wyman                  IBM Rochester 
 ( /_)  /  _  ' _   (507)253-2891           blairw@us.ibm.com 
__/__)_/_<_/_/_/_'  Opinions expressed may not be those of IBM. 







+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---