cni vs jni

cni vs jni

[Andrew Cagney]

[This was today's technical topic]

What are the advantages vs disadvantages of CNI over JNI.  Going 
forward, should Frysk stick with the GCJ specific CNI, or migrate to the 
more standard and accepted JNI.  Discuss.

- cagney noted that while CNI isn't going away, it certainly isn't being 
pushed [he keeps getting hints that frysk should break its dependency]

- MJW noted that the JNI is far more cumbersome for accessing class 
data, complex data types, and callback methods.  Reflection calls are 
needed to access those methods.  On the other hand full access to 
reflection becomes possible.

- MJW indicated that JNI works best when information is exchanged using 
simple types (e.g., ints) and simple interfaces.  Consequently it is 
best to perform large chunks of work in JNI with few and thin calls 
to/from Java.

- Tim noted [is this right] that CNI gives us a fast simple and 
efficient access to the Java interfaces from C++.  A switch to JNI would 
loose that; and a loss of one of the advantages of being able to code 
most stuff in Java.

- Swig was mentioned; Phil noted that he'd looked at that for the 
elfutils bindings but discarded it as it over exported the interfaces - 
for frysk only a focused subset of the interfaces need to be bound; 
Cagney also noted that Swig didn't understand the memory patterns and 
requirements of libraries such as elfutils.

- Phil asked if it was possible to combine CNI and JNI code; cagney 
indicated that it was (well sort of) as it is clumsy.

- cagney noted that pushing more functionality into the native layer 
could make it easier to add other, additional bindings (binding C++ is 
easier than back binding native java).

Possible options

- simplistically translate the bindings into JNI

- push more core code into C++ and move the bindings to a higher layer

- status quo

Schedule?

Re: cni vs jni

[Andrew Haley]

Andrew Cagney writes:
 > [This was today's technical topic]

 > Possible options
 > 
 > - simplistically translate the bindings into JNI
 > 
 > - push more core code into C++ and move the bindings to a higher layer
 > 
 > - status quo

Or port CNI to Sun's Java.  It's far from impossible, and as far as I
an see the only real obstacle is getting buy-in from the GNU C++
maintainers.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

Re: cni vs jni

[Andrew Cagney]

How does BC (binary compatible abi) fit into all this?
(I know frysk's build system needs to be changed, but there are 
compatibility issues?)

Andrew Haley wrote:
> Andrew Cagney writes:
>  > [This was today's technical topic]
>
>  > Possible options
>  > 
>  > - simplistically translate the bindings into JNI
>  > 
>  > - push more core code into C++ and move the bindings to a higher layer
>  > 
>  > - status quo
>
> Or port CNI to Sun's Java.  It's far from impossible, and as far as I
> an see the only real obstacle is getting buy-in from the GNU C++
> maintainers.
>
> Andrew.
>
>   

Re: cni vs jni

[Andrew Haley]

Andrew Cagney writes:
 > Andrew Haley wrote:
 > > Andrew Cagney writes:
 > >  > [This was today's technical topic]
 > >
 > >  > Possible options
 > >  > 
 > >  > - simplistically translate the bindings into JNI
 > >  > 
 > >  > - push more core code into C++ and move the bindings to a higher layer
 > >  > 
 > >  > - status quo
 > >
 > > Or port CNI to Sun's Java.  It's far from impossible, and as far as I
 > > an see the only real obstacle is getting buy-in from the GNU C++
 > > maintainers.
 > >
 > How does BC (binary compatible abi) fit into all this?
 > (I know frysk's build system needs to be changed, but there are 
 > compatibility issues?)

Interesting question.  

To be absolutely clear: you can use CNI with BC-compiled code right
now, given the right compiler options, but you end up with CNI code
that has to be recompiled if your Java code changes.  We could change
CNI so that CNI code didn't have to be recompiled when the Java code
changes, and this would be a Good Thing, but it would be a bit of
effort.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903