cni vs jni

[Andrew Cagney <cagney@redhat.com>]

[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?