Proposal for CNI/JNI problems

Sat Apr 1 00:00:00 GMT 2000

Per Bothner writes:
 > Gcj will (soon) digest JNI source as is. 
Very good.
 > We handle "compilation of Java+JNI source to native code"
 > using any C compiler combined JNI run-time support.
 > You will be free to use JNI. It's your choice: JNI gives you
 > portability, but it is much slower and much more tedious to 
 > use than CNI.
OK, let's push this a bit further. CNI is elegant and efficient
because it knows which VM it will be executed with, and can thus
take shortcuts. I guess that the discussion about a CNI+JNI
abstraction, or preproecessor mappings of one to the other
indicate that it is difficult if not impossible to exploit at
compile time additional information about object memory layout,
for a JNI source?
In other words, the semantics of JNI code prohibits all
CNI-like optimizations due to parsing complexity issues?
 > The current discussion is about a *third* option: Write your
 > application in CNI (mostly, perhaps with some conditional
 > compilation), and then use a special compiler (G++) that translates
 > your CNI source into a JNI binary. That binary will work with *any*
 > JVM that support JNI. That gives you the convenience of writing CNI,
 > and the speed of CNI when running on a CNI-supported platform. You
 > also get (most of) the advantage of JNI portability, since you can use
 > any JVM that supports JNI, but you are restricted to compiling your
 > native code using G++.
If a hypothetical G++ "emit-jni" option would generate JNI C 
(not C++ or heavily macro'ed) code, this restriction would
only hurt on machines that have no G++ (which could be overcome
by cross-compiling to C or native).
 > The goal is to give people (and library writers) options.
No doubt, JNI ABI compatibility would make CNI a much more
viable option. In this case, the major concerns seem to be
Hans Boehm's points (3) and (5), quote:
 (3) automatically JNIizing [CNI] code completely
 is essentially impossible
[Question is, how much ground can be covered? Good enough 
 for 90% of the usual applications using native methods?]
 (5) anything requiring significant gcc changes will
 delay the project appreciably
[Good point. How long will it take to add ability to link 
 against JNI-ABI compliant DLL's, by comparison?]
 b.