Proposal for CNI/JNI problems

Sat Apr 1 00:00:00 GMT 2000

Bernd Kreimeier <bk@lokigames.com> writes:
> How does this address compilation of Java+JNI source
> to native code? With or w/o the flexibility of TowerJ?

Separate issue, as I expained in a subsequent message.
We handle "compilation of Java+JNI source to native code"
using any C compiler combined JNI run-time support.
The current discussion is purely about how to write the
Classpath libraries, and any other application that
want to *optimize* for JVMs that use CNI, but still
JVMs that only support JNI. (The former may support
CNI *as well* as JNI; at gcj will soon support both.)
> If classpath and/or gcj requires CNI, and does not digest
> JNI source as is, then it is not the right tool for many
> purposes (like mine).

Gcj will (soon) digest JNI source as is. I don't know about
other projects using Classpath.
> Is the combined classpath+gcj roadmap acknowledging that 
> people do use, and will continue to use, JNI? Maybe I am
> missing something - I'd appreciate a cnfirmation. I can't
> make myself dependend on CNI/gcj, and I suspect I am not
> alone.

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. 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++.
The goal is to give people (and library writers) options.
-- 
	--Per Bothner
per@bothner.com http://www.bothner.com/~per/