[Java-gnome-developer] Java-Gnome: jni or cni

Tue Mar 16 12:36:00 GMT 2004

> -----Original Message-----
> From: Andrew Haley
>> Boehm, Hans writes:
> > My impression is that you need some restrictions on CNI to really
> > make it usable with a fully type accurate collector. But it's
> > unclear to me whether that matters.
> > 
> > If I understand the current CNI rules correctly, the intent is that
> > you should be able to store a reference to a Java object:
> > 
> > 1+) anywhere (in a suitably typed field?) on the stack,
> > 2+) In a suitably typed field of a Java object, or
> > 3+) In a suitably typed static field of a Java or CNI class.
>> The fact that you can store an object reference anywhere on the stack
> (even in an integer!) is surely an accident of the current
> implementation, not a design requirement. We should be able to switch
> to a precise scan of the stack using unwinder data and CNI programs
> shouldn't break.
I think it's important to pin down the definition here.
I don't think there's any way to avoid pointers to a java object
in a compiler-generated temporary. Thus those would need to be handled.
And theoretically, they could be
But I think there is a crucial design choice about when it's acceptable to
pass a pointer to a Java object as a "void *" parameter to some Java
-unaware code. I think this is important in that it affects the reusability
of existing code in a Java implementation.
Currently the (implementation-specific) answer is
"Almost always, so long as you do any null-pointer checks explicitly, and the
Java pointers aren't stored in malloc'ed data structures." (And the latter
restriction could be eliminated with a suitable replacement malloc. And
there should probably be an option to do so.)
If/when we switch to not scanning static roots by default, there will be
an added restriction that either the "legacy" code doesn't save the pointer in
a static location, or you turn on full static root scanning. With smart
pointers, presumably you will have to do a bit of extra work, but you can still
convert to a regular pointer if you do the explicit null checks?
I think if you change this to an answer of "never", we're back to something
that's perhaps closer to JNI than to the current CNI.
...
> > a) What happens if you have a Java reference
> > in a C union?
>> I would say that you can't do that with CNI.
You can say that. (And my impression is that Microsoft's "Managed C++" does take
this approach.) But then you've also said that you can't call arbitrary
C++ code with a Java reference, even if you recompile it. It's not clear to me
that a native code interface that can't be used to call arbitrary native code
is that useful. (More realistically, you would end up adding a layer that converted
Java pointers to handles, which could be passed to arbitrary native code. I
suspect the result would look a lot like JNI for the hard cases, though you
can still take shortcuts in many common cases.)
Hans