Re: CharSequence support

[Stuart Ballard]

Nic Ferrier wrote:
> 
> I've been thinking about this today.
> 
> Here's an example issue: if native code is combined then how do you
> throw an exception? With CNI you just use throw, whereas with JNI you
> have to obtain the class reference of the exception you're going to
> throw from the java environment and then use a function ptr to
> actually throw the exception.
> 
> I guess that you could choose one style and then auto translate into
> the other but then you've written a whole new language that native
> code hackers have to learn.

My theory (and this is entirely from an outsider's perspective, which
should be taken with an appropriately-sized grain of salt considering I
don't know CNI or JNI) would be something like this:

The ideal is obviously to write a program that can translate from CNI to
JNI. Since that is probably impossible (how can you tell that a given
"throw" statement is for Java code as opposed to being purely within
C++, for example) it seems to me that it is probably necessary to
perform some "annotation" of the CNI source code using symbols that are
#define'd to nothing. Then for the "throw" example you could do
something like
throw __CNI__ (whatever). Then an appropriate perl script or whatever
would look for the __CNI__ keyword and translate each C++ statement in
which it appears to the JNI equivalent.

I don't *think* it would be too hard to use only the one keyword and
recognize from context exactly what kind of statement this is (C++
implementation of a Java native method, call of a Java method from C++,
retrieving the value of a Java field, setting the value of a Java field,
throwing an exception, accessing an array...)

Since libgcj is part of gcc (I think?) it may even be possible to add a
switch to gcc that would require this __CNI__ keyword to be present for
all statements where it would be required. That way leaving it out would
generate an error in the libgcj build process as well as in the
JNI-translated build.

This wouldn't necessarily entail requiring perl (or even gcc) for the
build process, because we could ship a copy of the pre-translated code
in our tarball (much like we can ship a jar of our class files to save
users compile time, because they're architecture independent).

Stuart.