[Kde-java] Java KDE bindings and GCJ/CNI

[Richard Dale]

On Friday 03 June 2005 01:43, Hannes Wallnoefer wrote:
> I've looked at the KDE Java bindings a few times over the last years,
> and I always felt like this combination has some huge potential.
> However, I think that memory usage is currently so bad that it makes
> it all virtually unusable for real world desktop apps (something like
> 30 megs for a hello world app). If I remember correcltly the excessive
> JNI code is one of the main culprits, and a look at the code seems to
> rather confirm this view.
>
> My question is: How much better could this be if KDE-Java used GCJ
> with CNI based bindings? Has anybody done any work in that direction,
> so that we could say how the code would look and how much work that
> switch would be?
Because the bindings are autogenerated it isn't as hard as it sounds to 
generate either JNI or CNI bindings according to a configuration option. But 
the main reason that all language bindings libs are enormous is that you need 
a C++ class in the bindings for every C++ class you wrap. Then for each 
virtual method inherited, you need to implement callback code to allow them 
to be overriden in java. The biggest technical problem with the current 
bindings is that they don't have callbacks for all the virtual methods, and 
so if that was fixed, they'd get even bigger. 

Another option is to use the language independent autogenerated 'Smoke' 
library and interface it with it via Java dynamic proxies. That would mean 
there would only be one CNI or JNI method call to implement - Proxy.invoke. I 
was about to implement that about a year and a half ago as a replacement for 
the current bindings. Then that might be too slow, and the Smoke library is 
still very large.

The bindings are generated by a perl program 'kalyptus'. You can experiment 
with comparing JNI vs. Smoke implementations by editing 
kdebindings/smoke/qt/generate.pl or smoke/kde/generate.pl and changing the 
line '-fsmoke' to either '-fjni' or '-fjava' for the JNI and Smoke based code 
generation. Then type 'perl generate.pl' to generate the code. So 
implementing CNI bindings would mean adding a '-fcni' option to kalyptus, and 
redoing the marshalling code for converting between Java and C++ types.

-- Richard