[sword-devel] Java JNI bindings

[Joe Walker]

Paul Gear wrote:
> 
> Joe Walker wrote:
> >
> > Hi,
> >
> > Not sure I've seen an answer to this, and Troy may have a totally
> > different
> > answer, but to me JNI is sometimes useful if the native interface you
> > need is
> > very simple, and the functionallity it provides is complex, and no Java
> > alternative exists.
> >
> > Often the complexities of debugging JNI make for a total nightmare
> > time, and the
> > interface code is not intuative at all. I've been programming in Java for
> > several years and without doubt JNI is my worst experience. Websphere
> > tries
> > hard, but JNI takes he crown for horribility.
> >
> > I have some Java code to read sword data files if you are interested.
> 
> I know that it's not pretty, but i think that its the best way to ensure
> compatibility with the C++ libraries and take advantage of new features
> like compression, so i'd rather bind to the real API than use a rewrite
> if i can.

Given a working Java version which only took a day or so to write from
scratch given C++ source I'd say keeping up to date is a non-issue
unless you intend to change the format often (I hope not)

Let me add a few more things against JNI:

Speed - in my current assignment we are forced to use C crypto code
via JNI for DES3 instead of one of the many Java implementations.
The C code is up to 30 times slower. This may be an extreme example
but it does make a point.

Debugging - really do not under-estimeate how hard it is to debug
in 2 languages at the same time even trusty friends like printf or
println start to get confused with 2 languages potentially messing
with stdout/stderr.

Stability - A well written 100% Java program will be very crash proof.
Add a single JNI call and all of a sudden the chance or a core soars.

Portability - ...

Build Complexity - ...

Launch Complexity - Now I have to worry about my LD_LIBRARY_PATH/PATH
variables as well as my CLASSPATH variable

Joe.