× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Java on the AS/400
  • From: Blair Wyman <wyman@xxxxxxxxxxxx>
  • Date: Mon, 1 Jun 1998 12:14:51 -0500 (CDT)
  • In-Reply-To: <199805311739.RAA67230@out1.ibm.net>

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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.