[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