JNI - is it good?

[Federico]

Hello,

what do you think about JNI (Java Native Interface)?
I have to integrate C and Java, and now I know how to do it with JNI,
but I would like to listen to some experienced programmer how is it,
good, bad, be careful with this, etc.

Thanks a lot,
Federico

 

[Ted Rees]

Hello,

what do you think about JNI (Java Native Interface)?
I have to integrate C and Java, and now I know how to do it with JNI,
but I would like to listen to some experienced programmer how is it,
good, bad, be careful with this, etc.

Thanks a lot,
Federico

Be careful to perform all error checking. It's very tedious, but you will
get very mysterious crashes if you don't

 

[Scott Ellsworth]

Hello,

what do you think about JNI (Java Native Interface)?

I have used it for a few tasks and had good results. My usual rule of
thumb is to write all the code in Java first, then profile. Only if
there is a clear performance bottleneck do I then consider JNI, as there
is a lot of overhead.

There often is such a bottleneck- some numerical methods I tried out for
matrix inversion were a lot faster. Further, if you have a special
library that is tuned for your architecture, that can blow the doors of
general Java code. The LAPACK tuned for AltiVec on a G5, for example,
just screams, and is worth calling in native code.

On the other hand, if I am integrating with an existing compute bound
C++ app, a named pipe will often give the same performance for much less
effort. Depends on whether parsing and returning the data is a major or
a minor part of the task.

Scott

 

[Roedy Green]

what do you think about JNI (Java Native Interface)?
I have to integrate C and Java, and now I know how to do it with JNI,
but I would like to listen to some experienced programmer how is it,
good, bad, be careful with this, etc.

It is difficult. If you only have one problem to solve, it will be a
lot cheaper to get someone who has been there before to do it for you.

You need a textbook and lots of examples to look at. The sun docs by
themselves are not sufficient.

It is surprisingly slow. There is a terrible interpretive overhead on
each call. It does not compile thunks the way you would expect. So
you design so that you don't make many small calls. Go into C/C++ and
stay there a decent length of time to make the trip over the barrier
worthwhile.


However, it does let you do anything you could do in native code, so a
few drops of JNI can be like magic.

see http://mindprod.com/jgloss/jni.html

 

[Roedy Green]

On the other hand, if I am integrating with an existing compute bound
C++ app, a named pipe will often give the same performance for much less
effort.

By that do you mean a socket? Is C++ capable of talking to Java
pipes?

 

[Sam]

Hello,

what do you think about JNI (Java Native Interface)?
I have to integrate C and Java, and now I know how to do it with JNI,
but I would like to listen to some experienced programmer how is it,
good, bad, be careful with this, etc.

Thanks a lot,
Federico

I ventured into that territory last year to add some functionality to
a Java open source package that interfaced with a C++ native library.
Luckily, since it was a modification, I already had existing examples
in the code to work with. This was a good thing, since I have very
little C++ experience.

It worked out fine, but initially I did run into a problem where it
quickly ran out of memory. It turned out that I had to close a device
after each call, since I was opening it on each call (something like
that).

I would recommend reviewing the tutorial on Sun's site for JNI, and
compiling running through all the examples. That way you will get the
lay of the land and learn the nuts and bolts of JNI before you tackle
your application.

Good luck,
Sam90

 

[Scott Ellsworth]

By that do you mean a socket? Is C++ capable of talking to Java
pipes?

Not quite, though I have used sockets as well. Named pipes on a unix
system let you create a file that pumps data between two processes, such
as a C++ client and a Java server, or vice versa.

I usually create them with mkfifo on my MacOS X system.

The code is identical to that used to dump to a plain old file, but
using a fifo lets you avoid polling - the IO blocks until new data
appears.

I found a pretty good intro by googling on "named pipe".

http://www.linuxjournal.com/article.php?sid=2156

"One very useful application of named pipes is to allow totally
unrelated programs to communicate with each other. For example, a
program that services requests of some sort (print files, access a
database) could open the pipe for reading. Then, another process could
make a request by opening the pipe and writing a command. That is, the
``server'' can perform a task on behalf of the ``client''. Blocking can
also happen if the client isn't writing, or the server isn't reading."

Scott

 

[Roedy Green]

The code is identical to that used to dump to a plain old file, but
using a fifo lets you avoid polling - the IO blocks until new data
appears.

In Java only the System.in System.out and System.err can talk to one
of these named pipes, and Java itself knows nothing about the pipe. It
is set up purely in the script. There is no way to use a Java pipe
(PipedInputStream/PipedOutputStream) to talk to a C++ process.

Is that correct?

 

[Thomas Weidenfeller]

In Java only the System.in System.out and System.err can talk to one
of these named pipes, and Java itself knows nothing about the pipe. It
is set up purely in the script. There is no way to use a Java pipe
(PipedInputStream/PipedOutputStream) to talk to a C++ process.

Is that correct?

You are confusing terms, because they are confusing

Java Piped...Stream != Unix named pipe

As you for sure know, a Java Piped...Stream is useful only inside one
and the same Java program e.g. by communication between two threads of
the same Java application in the same VM.

A Unix named pipe (aka Unix FIFO) is an entry in a Unix file system. The
entry looks more or less like a file to an application, can be opened
like a file and can be written to and read from like a file.

The thing is, it is not a file, it is a pipe disguised as a file. If two
Unix processed open the "file", and one writes to it as writing to a
file, and the other reads from it, as reading from a file, the the one
reading just gets the output as written by the other.

This can be used in a number of ways to link otherwise unrelated
applications together. If you e.g. have a program which can just write
data to a log file, but you want to analyse and post-process the data
further before really writing it to the disk, you trick the application
into writing to a named pipe. And you start your post processor and
let it read from the named pipe.

Or, if you e.g. have a Java and a C++ program which should communicate,
and you don't want to use JNI or sockets, you just let one write the
data to a named pipe and let the other program read it from the named
pipe. Both programs don't have to know that they work with a named pipe,
they just think they work with a file. From their point of view they are
just doing simple file I/O.

Named usually just buffer 4k or 8k of data and do block to protect the
pipe from overflow or underrun. This blocks the file I/O in the
application. Which can block the application.

You create a named pipe in the Unix file system with the mknod Unix command.

/Thomas

 

[Scott Ellsworth]

In Java only the System.in System.out and System.err can talk to one
of these named pipes, and Java itself knows nothing about the pipe. It
is set up purely in the script. There is no way to use a Java pipe
(PipedInputStream/PipedOutputStream) to talk to a C++ process.

Is that correct?

Last time I had checked, a FileInputStream could talk to a fifo created
outside the java program with mkfifo. A
PipedInputStream/PipedOutputStream could not, as they do not descend to
the underlying os for this task. Admittedly, it has been a while and I
may be misremembering - I will check when next I get a chance.

Scott

 

[Federico]

Thanks to everybody, it's incredible how much help you provided!

Thanks a lot,
Federico