JNI support?

[Per Bothner]

> Does this mean that the JNI standardizes things like the memory layout
> of objects?

No.  You call a JNI function *at runtime* to get a field handle
(by specifying the field name), and then you use another JNI
function to access the field value using the field handle.

> How about libawt and other compiled code that's part of the JDK? It
> would be really really nice to be able to take these libraries and
> drop them into kaffe. They may not be Free, and the JNI may be slow,
> but at least they do work.

But they are only available on a small number of platforms.
Sun provides the libraries on Solaris2, Windows 95/NT, and (I believe)
MacOS.  Others may make them available for other platforms (such as
Linux), assuming someone with a source license has done the
necessary porting, is willing to redistribute the changes, and gets
permission from Sun to do so.

In addition there are legal problems using Sun's libraries with
Kaffe.  The way we use Sun's classes.zip with Kaffe is already
problematic, and is only acceptable as a stop-gap measure.

And of course, we have no idea how popular JNI will be.  Microsoft
does not want to support JNI, but may be forced to by their
license with Sun.  However, the license would not force them to *use* JNI
for any of their own libraries;  they only have to *implement* it.

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.

I think it would be nice to have a "Kaffe Native Interface".  This would be
a set of macros that could be compiled into *either* JNI or a
faster interface, using conditional compilation.  I don't know how
difficult or kludgy it would be to come up with something like that.

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