Tom Tromey <[EMAIL PROTECTED]> writes:
> Maurizio> But i CNI interface would not be another run-time layer,
> Maurizio> just a "conceptual layer" that the compiler strip away;
> Maurizio> that's the whole point of CNI, or i haven't understood it
> Maurizio> :-> ?
>
> I think you misunderstood. CNI is a fast way of writing native
> methods for Java that only works with the gcj/libgcj implementation.
> There is a paper about CNI on the gcj web site that describes the
> approach.
I read it ;->.
While what you say it is true, i don't think that it is the end of the
story; my point of view is that merging the ABI and runtime of Java
and C++ as the CNI is trying to do bring other advantages.
If any Java object is a C++ object, and i can call a Java method
directly from C++ as a C++ method, i can throw an exception, i can
instantiate a Java object just with a C++ 'new', i can reduce the
"translation layer" needed to integrate a piece of Java code to a
piece of C++ code.
My impression is that CNI allows designs where the layer adapting
between the Java view and the C++ view of the world is just (almost :)
a compile time entity; while JNI require more code translating back
and forth.
Well, at this point i don't know anymore if this point of view affect
the discussion over Java to GTK interfacing, but at least i made
my point clearer ;->
Maurizio
--
Maurizio De Cecco
MandrakeSoft http://www.mandrakesoft.com/
