On Dec 16, Stuart Ballard wrote:
> Paul Fisher wrote:
> > The JNI/CNI issue could be solved post agreeing to cooperate. I don't
> > see the JNI/CNI issue to be terribly important. gcj aims to support
> > JNI, but that code needs to be completed. I personally find CNI to be
> > extremely elegant (about 10 lines of JNI code correspond to one line
> > of CNI).
>
> Regardless of how cool CNI is, and I'm sure it is, it's not supported by
> most VMs, and probably won't be, so Classpath can't rely on it (unless
> we can somehow implement CNI *in* JNI? That would be nice.)
JNI is a very abstract interface to the virtual machine. It is made
in a way that it should be useful for any Java implementation. To
quote from the Introduction of the Java Native Interface Specification:
If you are implementing a Java VM, you should implement the JNI. We
(Javasoft and the licensees) have tried our best to ensure that the
JNI does not impose any overhead or restrictions on your VM
implementation, including object representation, garbage collection
scheme, and so on. Please let us know if you run into any problems we
might have overlooked.
CNI is of course much simpler and more efficient than JNI, but it
heavily relies on the layout of objects. Also it seems impossible to
use a copying or generational garbage collection with CNI, since the
native code may directly modify objects. CNI is not even compatible
against binary compatible class evolution.
I think we should only use JNI in classpath. We don't need another
abstraction layer, since JNI is abstract enough.
Jochen
