Proposal for CNI/JNI problems

[Bernd Kreimeier]

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