[212] in java-interest
Re: Native Methods Question
daemon@ATHENA.MIT.EDU (Chuck McManis)
Wed Jun 7 13:38:36 1995
Date: Wed, 7 Jun 1995 10:04:41 -0700
From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
To: java-interest@java.Eng.Sun.COM, kevinc@hppcih58.fc.hp.com
Cc: chrisk@hppcih58.fc.hp.com, detlef@hppcih58.fc.hp.com
>On Implementing Native Methods an example is given of file read and
>write routines being done in C. One of the details is that the C
>code sets the separator to / appropriately. My questions are :
>
>1) Isn't this C code going to be interpreted/executed on the client?
Yes.
>2) If the answer to #1 is yes, then how can I write a single program
> that "knows" things like which separator to use?
Because the C code is compiled for a specific platform, you know at
runtime what the separator should be. For example if you were compiling
the C code to run on a Solaris machine you would set them one way, if
you were compiling on an NT machine you would set them another. I
guess another way to say that is your "single" program would run on
only a "single" platform, not all possible Java runtimes.
Native code is NEVER dynamically downloaded and run and it is not portable.
So if you wished to distribute a class that had some native methods you
would have to have shared library objects for every platform that you
support. The Java code trys to supply Java interfaces to everything you
need so that you can avoid this but in some cases where specific hardware
or native libraries need to be interfaced too it is unavoidable.
Another caveat is to make sure your native code is re-entrant or if it
isn't there are appropriate synchronization primitives on the class
that is the interface to them. Several libraries "from the net" that
one might like to wrap a Java wrapper around won't work because they
use shared global variables between function calls.
--Chuck McManis
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
