JNI support?

[Peter C. Mehlitz]

On May 14,  4:46pm, Per Bothner wrote:
>...
> Note:  I agree Kaffe should support JNI.  However, it should also support
> a faster API.  The two goals do not necessraily conflict.  I just am
> not convinced that JNI is a terribly high priority for Kaffe.
> ..

Let me second this! Just about finishing the painful work of making biss-awt at
least JNI compatible, I do have some VERY mixed feelings about JNI as the sole
native interface.

For extensive field access, exchanging a simple unhand() macro (to access a
simple structure member) by - at least - one function call might be a matter of
go/nogo (we all remember the putc, don't we?). What you have to do to
circumvent this problem is to transfer as many fields as possible via parameter
lists (looks pretty uggly, exposing all the implementation details).
Unfortunately, you don't have access to many relevant fields in the "standard"
classes (e.g. java.awt.Color.value). With respect to array access, this is even
worse. Accessing elements by function calls is simply inappropriate (for all
but trivial cases). Copying in and out (because you can't rely on "pinned down"
arrays if you really want to get it portable) does not work for large arrays
(think of Images). The result is moving more and more data out of Java and into
the native layer (just storing them back in some kind of pData int fields) -
needless to say this is bad too. Besides, I have seen too many non-coexisting C
libs to expect not running into trouble (sooner or later) by using different
ones for the VM / the native libs. Linux folks are just a bit spoiled with
respect to that (because of the single libc).

I don't say that decoupling of memory models between the VM and the native lib
is useless. But I think it will work just for some very specific cases (large
native methods with sparse field access).

Peter