JNI stands for Java Native Interface. It allows a Java program to access C & C++
methods. By
using established C-to-Fortran bindings, you can also interface Java to Fortran using
JNI.
JNI will work for your purposes. Basically, you declare all of the C functions that
you want
to call as 'native' methods in Java. Then, you run 'javap', which parses your Java
code and
creates C "stubs" for all of the native methods (a stub is just a simple function in C
that
Java knows how to connect to). You then fill out these "stubs" to call the actual C
routines
that you intend to use.
There are some things that need to be pointed out concerning the C stubs. Any data
declared
in Java that will be used in the C programs must be copied to local C variables (JNI
provides
functions that retrieve data from the JVM). To store values in the JVM from C code,
you must
likewise copy the local C variables to Java (again, using functions provided by JNI).
The
reason that variables need to be copied (as opposed to being used directly) is that
Sun has
declared in the JNI specification that the JVM can, at its will, move variables in
memory
(supposedly, the forthcoming HotSpot JVM will move memory in order to reduce memory
contention between threads). If a C program were accessing data in the JVM directly,
the
pointer referring to the data would thus be out of date if the data had been moved by
the JVM.
This should get you the funtionality you require. JNI also specifies ways of throwing
and
catching Java exceptions, as well as ways of declaring new memory and garbage
collecting old
memory in the JVM. However, this functionality is rarely required, and adds
significantly to
the complexity of JNI programs.
I hope this helps!
-dan
[EMAIL PROTECTED]
Andrew McLaughlin wrote:
> Hi Diego,
>
> I'm a little dense in this area, can you break down the components? I'm thinking
>that I'll
> have to write my own software on the server side to be able to select data as well
>as do
> the normal I/O. While UniData does have a C adapter so that I can access the data
>files
> from Unix I'm not sure what else that I would have to write to complete the chain.
>
> Is JNI (Java Network Interface)? Just guessing. That's a new one for me.
>
> Am I on the right track?
>
> Thanks,
> Andrew (learning Java for one week so far)
>
> Diego Pons wrote:
>
> > Andrew McLaughlin wrote:
> > >
> > > Is anyone working with RMI so far? I'm launching into a project where I'll try to
> > > connect Sanfrancisco to a legacy database (UniData). While UniData does provide
>ODBC
> > > it's too slow and, gulp, read-only.
> > >
> > > I welcome any and all commentary with open arms and squinted eyes!!
> > >
> >
> > I'm using RMI in a project integrating a legacy RPC system with Java clients.
> > It works very well and I do not see any significant performance degradation
> > compared to regular RPC connections.
> >
> > If you decide to use JNI to interface directly to your legacy API, try very
> > hard to centralize the API into a single JNI call (ioctl-like). It is very
> > tedious and error-prone to develop JNI interface calls.
> > It took +50 lines of the ugliest C code per each argument/call.
> >
> > --
> > Diego Pons Pharos Consulting LLC
