Proposal for CNI/JNI problems

Sat Apr 1 00:00:00 GMT 2000

 [Just voicing opinion. I don't contribute, I'd just 
 use (if I can use, that is)]
Per Bothner writes:
 > (1) Is it OK to write Classpath in C++ rather than C? 
As long as portability isn't affected.
 > (2) Is it OK for Classpath to depend on G++ extensions?
Affects portability. Even if G++ is available, a second
compile option is always valuable during development,
especially when depending on an evolving and instable toolchain.
 > Tom Tromey suggested that the ideal way to let people write code
 > that is both JNI and CNI-compliant is to have a compiler that can
 > read CNI and emit JNI.
How does this address compilation of Java+JNI source
to native code? With or w/o the flexibility of TowerJ?
 > JNI is an Application *Binary* Interface.
It is also an API specification.
 > All we need do is have G++ have an option to generate JNI calls.
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).
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.
 b.