Re: Proposal for CNI/JNI problems

[Bernd Kreimeier <bk@lokigames.com>]

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.