Stuart Ballard wrote:
> > One of the goals of the Classpath project is to remain VM-neutral.
> > Using JNI supports this goal.
Doesn't this settle the issue then?
> Or, we could implement one in terms of the other, or implement an
> abstraction layer over the top that allowed C code to use whichever was
> appropriate.
IMO the only thing required to make Classpath/Japhar/Kaffe modules
work with Gcj is JNI support in Gcj. Which, I am told, is under way.
I am not sure I understand where this discussion is heading?
If somebody has the resources and the inclination to rewrite a JNI
Classpath/Japhar/Kaffe component later to port them to CNI, more
the power to them. If supporting CNI, or adding abstraction layers is
the price of admission, I wonder whether the tail is wagging with the
dog.
JNI is defined to enable *binary* compatibility. If I create a JNI DLL,
ideally it should work with all VM's on the same (e.g. ELF x86) platform.
The price for this promise (far from reality) is significant performance
loss depending on your use of JNI.
Re: licensing. Kaffe is under a "somewhat" GPL. Creating a native
executable that invokes a VM e.g. to use RegisterNatives, or loading
a Java class that has native methods, constitutes linking. I take it
that Japhar decided to use LGPL after much discussion (and against
RMS wishes) to accomodate close source code. Tim Wilkinson explained
to me that Transvirtual's interpretation of the GPL does not prevent
such uses (embedded Java, using Kaffe AWT with a different VM).
Between invocation, native methods in DLLs, dynamic class loading and
reflection, it is near impossible to trace all dependencies of a given
Java program for a given core class/VM combination. Putting the VM,
or any native library, under GPL, might make embedded use impossible.
I am not sure I understand what FSF and Cygnus are negotiating at the
moment, and I would appreciate some reassurance that the GPL vs. LGPL
decision Japhar took is taken into account.
b.
b.
>
> Is it possible to implement CNI in JNI without a terrible performance
> hit? In other words, would it be possible to write our library code to
> use CNI, such that in gcj that will be used directly, and in other VMs
> it would go through JNI? This has the advantage too that our library
> code can use the simple and elegant CNI interface rather than JNI.
> However it has the disadvantage that many more programmers know JNI than
> CNI, so we add some barrier to entry; there's also the performance hit
> of using a wrapper library.
>
> Another approach that might work better would be to use a third
> interface which was designed to map easily to *either* approach, perhaps
> using C macros to eliminate the performance hit. Since I don't know the
> details of either JNI or CNI I can't really speculate as to how that
> might work, except that it *sounds* plausible.
>
> Anyone have any thoughts on this?
>
> Stuart.
>
> PS I agree that "agreeing to work together" is more important than the
> technical issues, but there's no reason that they can't be discussed in
> parallel...
--
"Problem solving is hunting. It is savage pleasure,
and we are born to it." Thomas Harris, Silence of the Lambs
