JNI support?

[Per Bothner]

darknerd at best.com writes:
> For Java, this means any Java applet could access compiled byte code
> libraries.  Thus, if Kaffe doesn't support JNI, then it cannot use the
> Java libraries from another vendor.

This is at best misleading.  JNI does not allow "any Java applet could
access compiled byte code libraries", since Java already does that.
The Java .class format defines a machine-independent ABI.
That is the whole point.  Even without JNI, Kaffe can use Java
libraries from another vendor.  What JNI provides is the ability to
use a *machine code* library from another vendor, *if* it has been
compiled for the same architecture and calling convention (and
uses the JNI).  That is, JNI is defined in terms of some existing C ABI.

For Kaffe, JNI as an ABI has limited usefulness, especially if
you are running on a platform that is not comerically popular.
How many Netscape plug-ins run on Linux?  Except for those available
with source code - very few.  JNI libraries will be the same.

Thus for the proponents of free software, the JNI is not very
exciting as an ABI.  It *is* useful as the only standard A*P*I for
calling between Java and C or C++.  However, as such it has quite
substantial overheads.  For example, you need to do an indirect
function call to access the value of a field of the current class.

Therefore, I think it would be a mistake to implement the core
Kaffe native methods using the JNI.  It is doable (and I am told
Sun does this in JDK 1.1), but it is very expensive.  (I suspect
the relative overhead is acceptable only because Sun's Java
implementation is relatively slow.)

I think Kaffe should provide JNI support, but it should also provide
a more efficient native interface.  The latter will use the same
calling convention as JIT-compiled Java methods.  There needs
to be some way to select between the two native interfaces.

That leaves the question as what the *fast* native interface will
be.  For now, we have the existing interface for native methoda
(based on javah).  It is somewhat clunky and poorly specified, but it
works.

Longer-term, I would like to modify G++ so that it can work with
Java-style classes, and read class definitions from .class files.
Such classes would be laid out in memory in the same way that
Java classes are laid out  This will allow writing native methods
using C++ in a very natural way.  I believe the Supercede Java IDE
already supports something similar.

As a very hypothetical example of what I mean:

extern "Java" {
#include "java/lang/Object.java" // ???
}

jint Object::hashCode ()
{
  /* Hash code is object's address */
  return (jint) (jword) this;
}

	--Per Bothner
Cygnus Solutions     bothner at cygnus.com     http://www.cygnus.com/~bothner