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

Thomas Zander zander at kde.org
Wed Jun 15 14:11:10 CEST 2005


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.

> > 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.
And operatior== -> equals()

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?

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 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.

> > 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 :)

-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-java/attachments/20050615/f8d114c2/attachment.pgp


More information about the Kde-java mailing list