Anthony Green wrote:
>
> One of the goals of the Classpath project is to remain VM-neutral.
> Using JNI supports this goal.
>
> Libgcj, on the other hand, was written solely in support of the gcj
> execution environment. Using CNI is important for performance
> reasons.
That's why I brought up the issue, because I could see that it was a
point of difference in the objectives of the two projects.
> 2. Merge the projects into a single source base in support of all of
> our combined goals.
[snip]
> [2] is also possible. It will require developing a new build system
> in which we can specify JNI or CNI bindings. In libgcj, we currently
> put CNI code in the directory with the java source. It's easy to
> imagine creating cni and jni subdirectories for each package and
> maintain that code separately. It's a little more complicated than
> this - but that's the general idea.
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.
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...