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

[Richard Dale]

On Wednesday 15 June 2005 14:11, Thomas Zander wrote:
> On Wednesday 15 June 2005 11:45, Richard Dale wrote:
> > > I really don't know where
> > > Java support is right now and what is still missing
>
> ...
>
> > 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.*.
>
> Yeah; thats a really big and ugly solution which made my bash complain
> about not being able to fit all classes on one command line for
> compiling.
Yes, the problem is that java package names have to be used in the types of 
java slots/signals, because the import context for the current class is a 
compile only thing, and there is no reflection api for discovering it at 
runtime. This means that fully qualified class names must be used within 
connect(), unless you can cheat by assuming the every class beginning with 
'Q' is in org.kde.qt and every class beginning with 'K' is in org.kde.koala. 
Once you have the subpackages, it means you have to fully qualify the 
classname within a connect() statement. Hence, the suggestion for dropping 
'org.kde' as part of the package name - qt.QWidget looks better as an arg 
type in a SLOT(), than 'org.kde.qt.QWidget'.

> > > 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.
>
> I'm curious how smart a move it would be to do so as with the new
> technologies being available the result might be sub optimal.
> Using GCJ instead of JNI combined with good wrapper classes would IMO make
> various traditional problems go away.
> First is that the C++ language has various limitations that are ugly in
> the eyes of any Java programmer.  Doing away with those will make the
> library easier to use due to a less steep learning curve.
> Things that come to mind are starting to use exceptions and renaming foo()
> to getFoo() plus the creation of a signal object for any signal/slot
> connection.  Also the generous creation of final methods in the wrapper
> class to make sure people don't go overriding non-virtual methods.
Yes, that would be an improvement, but it's just a code generation thing, and 
not a runtime thing and so it is quite easy to implement in kalyptus.

> And operatior== -> equals()
Yes, operator methods are renamed as 'op_plus()' or 'op_equals()' at the 
moment, so that looks better for the operator== case.
 
With the Smoke/dynamic proxy approach it is easy to remap method names at 
runtime. A call to getFoo() can be remapped on get() in the Proxy.invoke() 
method that interfaces with the Smoke library.

> Personally the whole reason I never touched the java bindings before is
> that it uses JNI; a technology that is broken by design.  I want to find
> out if using gcj gives me more freedom and a faster runtime.
> For that reason I'm not sure I like the proxy approach you suggest. I take
> it it uses some means of reflection?
Well it uses proxies.. In Proxy.invoke() you have access to the method name 
and the types of the args. Smoke has an introspection api, and it is more to 
do with looking up the corresponding C++ method in the Smoke library, by 
matching the arg types if the method is overloaded, and not to do with java 
reflection.

> My idea was to generate classes that do nothing but wrap the kde libs and
> create some classes with static methods that do any needed conversion on
> the from the jint/jfloat to the native versions.
>
> Something like:
>
> namespace java {
>   class KAboutDialog public java::KDialogBase {
>      public:
>        void setTitle (java::QString &title) {
>            member->setTitle( title.member );
>        }
>        int setFoo(jint foo) {
>          int answer =
>            member->setFoo( Converters::intConverter()->convert(foo) );
>          return Converters::intConverter()->convert(answer);
>        }
>      private:
>        KAboutDialog *member;
>   }
> }
The problem is that this doesn't deal with overriding virtual methods, and you 
also need to be able to call C++ protected methods from java. 

> The biggest problem I see for this is the generation of good Docs since we
> don't have all methods in Java, we can't easily create Javadocs for them.
> There are so many essential things missing in the doxygen generated docs
> that Java developers are used to having in their docs.  I feel that this
> documentation in standard javadocs is an essential part of the bindings
> for Java.
I would say that kalyptus does a pretty good job at converting doxygen 
comments to javadoc ones. I prefer looking up things in the KDE api via the 
java javadocs than the C++ doxygen ones.

> > > 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.
>
> Sounds like we can share experience and create the best solution in the
> process :)
Yes indeed, we need to get some sort of collaborative effort going..

Will you be coming to Malaga? I'd like to get as many people as possible 
together there to discuss the java bindings in Qt4/KDE4.

-- Richard