Re: (no subject)

[Etienne M. Gagnon]

Hi.

> I've mentioned to Tom recently in private email that we should
> probably just plan on having both CNI and JNI implementations in
> Classpath.  Kaffe and gcj can both use CNI, which makes JNI less
> important going forward unless the SableVM, the Intel VM, or some
> other VMs really like having that.

JNI has been explicitly designed as to remove any dependency between the
VM's internal binary representation of objects and algorithms (e.g.
garbage collection), and the library native code.

Furthermore, JNI is a low-level binary interface, which dictates how the
actual linking will happen at runtime.  This allows for compiling native
code once, then using it with various VM's on a given platform.  So, you
should be able to write some native library, and run it with SableVM,
Japhar, Kaffe, and other VM's on Linux, without recompiling your
library.

CNI can be seen as a nice C++ wrapper around a low-level native
interface.  CNI has the advantage, *** for C++ developers ***, to
provide a more intuitive programming model than pure low-level JNI. 
But, CNI should not be seen as the native interface.  From what I
remember, it seems possible to rewrite the current implementation of CNI
to wrap the JNI native interface, instead of the current VM specific
native interface it wraps.  I personally think that Classpath should not
move to CNI, unless such an implementation is written.  Currently, CNI
does not offer the binary representation independence required between a
VM and the native code.

Remember that a VM should be free to layout objects as it sees fit.  For
example, SableVM's objects grow in 2 directions, above and below the
object header.  This fits poorly with CNI.  SableVM even plans to
provide, based on a runtime option, distinct object layouts.  SableVM
also uses a copying collector, which moves object around in memory. 
This is not feasible without the isolation provided by JNI.  Again, if I
remember correctly, the current CNI does not allow this.

So, please think carefully before you decide to switch to CNI.  As far
as SableVM goes, for the reasons cited above, it's native interface will
remain the standard JNI.  SableVM needs Classpath (with JNI)!  

Regards,

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: address@hidden
Author of SableCC:                             http://www.sablecc.org/
and SableVM:                                   http://www.sablevm.org/