Re: Classpath future?

[Brian Jones]

"Nic Ferrier" <address@hidden> writes:

> >>> "Etienne M. Gagnon" <address@hidden> 12-Jul-01 7:11:18 PM
> >>>
> 
>    It is my impression that by now, most people on 
>    this list, agree that this issue should be resolved 
>    simply keeping 2 separate native branches, 
>    one for JNI, and one for CNI.  Remains to decide 
>    if we want to put some rules on the synchronization 
>    of both trees.  Right?

Yes, we have two tree, one for jni and one for cni.  Waited a year for
another solution everyone liked and none appeared.  Decided to stop
waiting and do something and that is what we're currently doing.
We're always willing to look at a better mouse trap... but I'm not
holding my breath for it.

> My view is that there should be an "example native" which is actually
> the japhar native and is built using JNI.  Other natives (eg: GCJ,
> Kaffe) should be supplied by the VM vendor (though they maybe
> distributed with Classpath)

It isn't like that.  The native code we have is not VM specific, but
JNI or CNI specific.  We actually don't provide any native code for
the Japhar specific native methods you might find Java counterparts
for in vm/reference/.  Check it out... see for yourself.

> I think it should be this way because VMs other than GCJ might want
> to implement some of the native stuff in there own way, Kaffe for
> example uses it's own native protocol (which is handled by kaffeh) and
> some of their native code has to be specific to them. 

Tim W. has recently been pulling all KNI out of Kaffe, apparently in
favor of JNI.  I don't think KNI will last much longer.

-- 
Brian Jones <address@hidden>