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

[Hannes Wallnoefer]

On 6/3/05, Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> 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.

Thanks for the explanation. My belief was that CNI would be generally
sleeker than JNI, and that it would be possible to mirror the
hierarchy of Qt/KDE classes to the CNI stubs and get smaller classes
in result. But looking a bit closer, that may not be the case (except
for the constants defined in the JNI stub header file for each
Widget... but I do not know if these affect the size of the library
that much). Well at least the code would be much easier to implement
and much nicer to look at with CNI :-)
 
> 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.

Thanks for the hints. Maybe I'll give it a try. I'm usually a bit
scared by huge perl scripts, but it doesn't look that bad.

Hannes

> -- Richard
>