On Sat, 2004-03-13 at 20:33, Momchil Velikov wrote:
> Bullshit, sorry.
Thanks for your politeness. I don't think that anything coming after
such a sentence is worth discussing.
Best regards,
Tom
Thomas Aeby, Kirchweg
> "Thomas" == Thomas Aeby <[EMAIL PROTECTED]> writes:
Thomas> On Thu, 2004-03-11 at 18:44, Mark Howard wrote:
>> The big question is: should we switch to CNI?
Thomas> Actually you already know the answer. Will you rename the
Thomas> "java-gnome" project to "gcj-gnome"? If not,
On Thu, 2004-03-11 at 18:44, Mark Howard wrote:
> The big question is: should we switch to CNI?
Actually you already know the answer. Will you rename the "java-gnome"
project to "gcj-gnome"? If not, stay with JNI, if yes, do this step
with all consequences - you are talking about a library, then,
Per Bothner wrote:
...
then a pre-processor can generate the JNI or CNI headers.
...
My main worry is that the programmers using these macros might not take
the good approach to JNI programming (which consists of "caching" method
and field ID's) if some macro hides method/field accesses.
Also, fro
On Thu, 2004-03-11 at 09:44, Mark Howard wrote:
> The big question is: should we switch to CNI?
As much as I like CNI, and want to promote gcj usage, and to the extent
that supporting both CNI and JNI is not an option, then I believe that
java-gnome should stick with JNI.
I don't believe there ar
I think it is a good idea to keep JNI support, but provide
CNI using a hybrid approach.
For example we can replace:
JNIEXPORT void JNICALL Java_org_gnu_gnomevte_Terminal_vte_1terminal_1feed
(JNIEnv *env, jclass klass, jint handle, jbyteArray data, jint length){
BODY
}
by:
NATIVE_METHOD(org.gnu
On Fri, 2004-03-12 at 04:44, Mark Howard wrote:
> The big question is: should we switch to CNI?
My experience is running through some of the java-gnome tutorials, using
gcj to compile 'native executables'. I just used whatever defaults were
there, and from what you say below it is currently jni. I
7 matches
Mail list logo
