[Kde-java] Java KDE bindings and GCJ/CNI
Richard Dale
Richard_Dale at tipitina.demon.co.uk
Fri Jun 3 10:18:51 CEST 2005
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
More information about the Kde-java
mailing list