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

[Richard Dale]

On Thursday 16 June 2005 13:44, Thomas Zander wrote:
> > The goal is not to create a Java kdelibs API from scratch, the goal is
> > to bind Java to the kdelibs API so that one can use KDE classes in Java
> > and the other way round.
>
> Ehm; no. I don't agree on that goal. If thats the goal then expect pretty
> bad uptake from Java programmers.
> At FosDem I talked to the java-gnome bindings guy and he created a lot of
> stuff that is not in the gnome libraries (event handling for example);
> and that works. People use that.
Have you seen this comparison between the java-gnome bindings and the GTK# 
ones:

http://people.redhat.com/~graydon/csharp-java/

It seems the main difference is in the event listener stuff vs. csharp 
delegates. For QtJava we could add a similar layer of event listeners classes 
on top of the autogenerated bindings, probably based of 
QObject::eventFilters. Then it might look more familiar to a java programmer. 
I've never programmed event listeners, so I'm the wrong sort of person to 
judge whether they look 'more java-like', than signals/slots or subclassing 
event handling methods in QWidgets.

On the kdebindings at kde.org list, Ashley Winters is discussing his ideas for 
Smoke v2. I would much prefer all new language bindings to use the same 
library for KDE 4. I don't think this affects our recent discussions on the 
look of the api, to me that seems independent of whether or not to use JNI or 
CNI, and/or the Smoke library. He is proposing generating bindings via a 
translation unit dump of the compiled object code to xml, followed by XSLT 
transformations to generate the C++ code for the Smoke lib. It does lose the 
comments in the headers though, and I still think we need a header parser to 
generate the javadoc comments from the doxygen ones. Or to look for methods 
marked with a '@deprecated' tag, and not add them to Smoke

-- Richard