[Kde-java] Re: GCJ (Re: Build system for KDE4)

[Richard Dale]

On Tuesday 14 June 2005 18:29, Thomas Zander wrote:
> On Tuesday 14 June 2005 16:50, Richard Dale wrote:
> > On Tuesday 14 June 2005 17:00, Martijn Klingens wrote:
> > > Richard Dale said:
> > > > I'm too busy with ruby recently to do anything with java, but we
> > > > really need to make more effort. If lots of people start using the
> > > > java bindings I'll fix any problems they come up with. I'm not
> > > > really an autotools expert, but somebody from Redhat or similar
> > > > should sort out getting the java bindings working with KDE.
> > > > Java-Gnome seems similarly under-resourced from what I've read, and
> > > > depending on about one guy.
> > >
> > > What exactly is needed? Can I start creating tests for KExtProcess (a
> > > C++ lib) in Java and just add footest.java to the make check targets,
> > > or is more needed? I really don't know where Java support is right
> > > now and what is still missing, I only started looking into it a
> > > couple of days ago, and my time is *really* limited atm.
Compared with the python or ruby bindings, you can't override all virtual 
methods. So the java bindings wouldn't be so suitable for writing custom 
widgets. But if you just want use the existing Qt or KDE widgets you can 
connect them up with signals and slots, and override event handling methods 
and so on. PyKDE and ruby Korundum have about 1000 classes wrapped, and the 
java bindings had about 800 last time I counted. But enough of the KDE 
functionality is there to write useful apps.

Other things that could be improved are the package/class names. At the moment 
everything is in two giant packages org.kde.koala.* and org.kde.qt.*. I'd 
like to change it to qt.QWidget and kde.KApplication instead, as the 
'org.kde' bit just seems redundant noise, and split up the packages so there 
is about one java package per underlying C++ library with names likes 
'kdecore', 'kdeui' and so on.

Signals aren't emitted in a type safe manner at the moment, and the proxy 
based Smoke bindings have a scheme for solving that - but it's a marginal 
problem really.

> > > All I know is that interest is increasing -- me, Boudewijn, Thomas
> > > Zander, and more all want to have more solid Java support through CNI
> > > bindings with gcj.
> >
> > Oh, this is really good news. With the Summer of Coding Google
> > competition about two thirds of the entries have been for Qt/KDE java.
> > So lets coordinate to try and make it take off..
>
> What Martijn said is about all I also know about how to go about it; and
> my ideas on this means its probably going to be a waste of time to do
> anything like this for kde 3.x.  I'd like to start doing stuff in KDE4.
The kalyptus tool that generates the bindings works fine with the Qt4 headers, 
and I don't think there's a need to rewrite that. It's quite easy to change 
it to generate code for a new bindings design. On the other hand if it was 
written in java rather than perl, more java programmers might be able to 
maintain it.

At the moment there are two generation options; '-fjni' generates the current 
JNI based bindings, and '-fjava' generates bindings that use dynamic proxies 
to interface with the language independent 'Smoke' library. My prefered 
solution would be to use Smoke in conjuction with CNI. You only need to have 
one native method with the Smoke approach, Proxy.invoke(), as every method 
call from java is diverted to that. So it would be relatively easy to produce 
both JNI and CNI versions. The disadvantage is that a call via a dynamic 
proxy is about twice as slow as a normal call. In practice, JNI is pretty 
slow anyway and the current bindings still seem fast enough. Possibly dynamic 
proxies + CNI might be about the same speed. Dynamic proxies used to be very 
slow in gcj, and I'm not sure if they've speeded them up yet.

> After 5 years of only programming Java, I recently came back to C++ (and I
> hate it, a lot!) to do usability-bug-fixing in kdepim. But I need the
> experience to be able to make a KDE a better target for Java programmers.
Yes, I think it is easier to program KDE in java than C++.

> Note that its just a goal for me, at this moment, I have a general idea on
> how to go about it but I never created bindings before.
Well I've got nearly 5 years of only programming language bindings, apart from 
7 months doing some paid work in the middle of it. But QtJava was my first 
and only java project. It's just another language to me - so I'm not steeped 
in the java community, don't understand the point of ant and that sort of 
thing.

> ps. I do feel strengthened by the interrest in KDe/Java from the summer of
> code students :)
Yes, I hope it sparks a general revival of interest. I hope to give a talk 
called 'The State of KDE Languages Bindings' at Malaga, and it would be nice 
to get as many people as possible together there to discuss ideas for Qt4 
java bindings.

-- Richard