GCJ (Re: Build system for KDE4)

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

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.

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.

ps. I do feel strengthened by the interrest in KDe/Java from the summer of
code students :)

--
Thomas Zander

Martijn Klingens

2005-06-14 17:58:15 UTC

(I didn't know about the kde-java mailing list, it's not on
http://www.kde.org/mailinglists/, I already mailed webmaster about it, and
added links to developer.kde.org. Now I'm subscribed, so you can keep me off
the CC.)

Post by Thomas Zander
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.

Likewise for me, I just asked Richard what the status is. If the build system
supports it I could play with it before, but if serious work is needed I may
or may not do so.

So, suppose I have a C++ library and want to write unit tests in Java, what is
*NOT* there yet in terms of infrastructure to allow this?

Post by Thomas Zander
ps. I do feel strengthened by the interrest in KDe/Java from the summer of
code students :)

Same here :)

--
Martijn

Richard Dale

2005-06-15 09:45:14 UTC

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.

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

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.

Post by Thomas Zander
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++.

Post by Thomas Zander
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.

Post by Thomas Zander
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

Thomas Zander

2005-06-15 12:11:10 UTC

I really don't know where
Java support is right now and what is still missing

...

Post by Richard Dale
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.

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

Martijn Klingens

2005-06-15 13:15:02 UTC

Do you have to wrap KDE libs? I understood from our talks and from
http://www.valdyas.org/fading/index.cgi/hacking/javalib.html?seemore=y
that it is possible to import and call C++ classes directly with gcj
without the need to wrap anything at all. That's why I like this idea so
much, because the bridge between both worlds is by definition in sync with
no bindings needed at all.

Post by Thomas Zander
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.

This looks like an implementation detail to me though, plus I wouldn't be
surprised if doxygen is able to output javadocs.

--
Martijn

Richard Dale

2005-06-15 12:41:45 UTC

Can you subclass a C++ class in java and override C++ methods, and call
protected methods? I've forgotten, I need to read up on CNI and find out.

Post by Thomas Zander
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.

This looks like an implementation detail to me though, plus I wouldn't be
surprised if doxygen is able to output javadocs.

I think the javadocs for the current KDE bindings look fine. But the javadocs
for the Qt classes are missing though because the qdoc comments are in the Qt
sources rather than the headers. And kalyptus only parses the headers.

-- Richard

Tom Tromey

2005-06-15 16:07:34 UTC

Richard> Can you subclass a C++ class in java and override C++ methods

Unfortunately no.

CNI isn't really a full C++/Java bridge. There doesn't seem to be a
good way to make one, really, since C++ is so much more expressive
than Java.

CNI is more like a convenient way to write native methods in C++, and
a way to access Java code from C++.

Tom

Martijn Klingens

2005-06-15 19:23:21 UTC

Post by Tom Tromey
CNI isn't really a full C++/Java bridge. There doesn't seem to be a
good way to make one, really, since C++ is so much more expressive
than Java.
CNI is more like a convenient way to write native methods in C++, and
a way to access Java code from C++.

Ok, to make sure that I get it right: if I have a C++ lib and want to write
Java unit tests I would first need to wrap the C++ lib? That'd be a rather
large setback for me.

Also, the other way round, writing a lib in Java and the tests in C++ would be
far more simple? (As that's exactly the case I do *NOT* need it's useless for
me, but trying to get things straight.)

--
Martijn

Thomas Zander

2005-06-15 20:50:16 UTC

Ok, to make sure that I get it right: if I have a C++ lib and want to
write Java unit tests I would first need to wrap the C++ lib? That'd be
a rather large setback for me.

As I understand it, using CNI its currently like this;

From Java you can't extend a C++ class (as all Java objects have to extend
java.lang.Object).
From Java calling a method with native types (non objects) is impossible
due to byte-ordering and stuff, you have to use jint in C++ instead.
All methods called in Java have to be defined in Java, much like header
files in C++. So if you want to call a method that returns a QString you
need a java class QString.

This last point is the one you fear; but thats just from a compiling point
of view. I don't see any big reasons why most of this can't be automated
or done on runtime. But that needs investigation and probably code.

Post by Martijn Klingens
Also, the other way round, writing a lib in Java and the tests in C++
would be far more simple? (As that's exactly the case I do *NOT* need
it's useless for me, but trying to get things straight.)

Apparently doing Java things from C++ has been the focus point of GCJ. Not
the other way around.
Technology like gdirect (still alpha quality) can make various variable
matching problems go away due to the design where loading the Java class
for the first time will make it look up and create the native 'wrapper'
code for you.
There does not seem to be a one-stop solution here; we will probably have
to do some more thinking and possibly some auto-generating ourselves.
I have no good answer to this question right now.

--
Thomas Zander

Richard Dale

2005-06-16 04:36:03 UTC

Ok, to make sure that I get it right: if I have a C++ lib and want to write
Java unit tests I would first need to wrap the C++ lib? That'd be a rather
large setback for me.

If a qtjava method returns an instance that was allocated in the C++ world, it
will create a new java instance to wrap it. So as long as you only need java
classes which are defined in the bindings in the test driver, that will work.
But if you have your own C++ classes, and want to call methods on them that
aren't in the java bindings, then you would have to write your own bindings
for those classes.

Post by Martijn Klingens
Also, the other way round, writing a lib in Java and the tests in C++ would
be far more simple? (As that's exactly the case I do *NOT* need it's
useless for me, but trying to get things straight.)

Easier to do in CNI than JNI, but the java bindings don't really to anything
to help with that case.

-- Richard

Martijn Klingens

2005-06-16 07:38:34 UTC

Post by Richard Dale
If a qtjava method returns an instance that was allocated in the C++
world, it will create a new java instance to wrap it. So as long as you
only need java classes which are defined in the bindings in the test
driver, that will work.
But if you have your own C++ classes, and want to call methods on them
that aren't in the java bindings, then you would have to write your own
bindings for those classes.

Unless that can be automated somehow that's really not worth it for just
the test apps. (Reason I want to write those in Java is because AFAIU Java
shines in unit tests compared to C++, I have already written most of the
C++ lib, and the time is not right for adding a dependency on Java on the
lib itself whereas for just the tests it is IMO acceptable.

--
Martijn

Richard Dale

2005-06-16 06:51:34 UTC

The java bindings are autogenerated - the kalyptus tool is driven by a list of
headers in kdebindings/smoke/qt/header_list. It should be a matter of adding
your library headers to that list, then editing the 'generate.pl' script in
smoke/qt changing the kalyptus option '-fsmoke' to '-fjni', then type 'perl
generate.pl'. It will generate .java and .cpp sources. You then use javah to
generate the .h files from the compiled java classes.

But the package names are hard coded - any classes beginning with 'Q' go into
org.kde.qt and all others go into org.kde.koala. So maybe when we decide on a
better package naming scheme, the bindings generator ought to allow any Qt
headers to be used for bindings generation and not just the ones in the Qt
and KDE libs. Maybe a configuration file is needed for C++ classname to Java
package/classname mappings.

-- Richard

Martijn Klingens

2005-06-16 08:18:52 UTC

Post by Richard Dale
The java bindings are autogenerated - the kalyptus tool is driven by a list of
headers in kdebindings/smoke/qt/header_list. It should be a matter of adding
your library headers to that list, then editing the 'generate.pl' script in
smoke/qt changing the kalyptus option '-fsmoke' to '-fjni', then type 'perl
generate.pl'. It will generate .java and .cpp sources. You then use javah to
generate the .h files from the compiled java classes.

Hmm, with some small changes it can indeed be made generic enough to
support libs other than qt and kdelibs too. In theory it can even become
part of the build system to auto-import a C++ lib into Java code and do
all the binding generation and linking automagically.

Post by Richard Dale
But the package names are hard coded - any classes beginning with 'Q' go into
org.kde.qt and all others go into org.kde.koala. So maybe when we decide on a
better package naming scheme, the bindings generator ought to allow any Qt
headers to be used for bindings generation and not just the ones in the Qt
and KDE libs. Maybe a configuration file is needed for C++ classname to Java
package/classname mappings.

In the case of kextprocess it's namespaced C++ code. There's the
KExtProcess namespace with several classes in it. The most 'natural'
namespace for Java in terms of typing and grouping would probably be
<classname>.extprocess.kde.

--
Martijn

Thomas Zander

2005-06-16 09:00:05 UTC

Post by Richard Dale
But the package names are hard coded - any classes beginning with 'Q' go into
org.kde.qt and all others go into org.kde.koala. So maybe when we decide on a
better package naming scheme, the bindings generator ought to allow
any Qt headers to be used for bindings generation and not just the
ones in the Qt and KDE libs. Maybe a configuration file is needed for
C++ classname to Java
package/classname mappings.

Remembering a conversation on kdecore-devel about namespaces; the
consensus was that kdelibs was not going to be adding namespaces, meaning
most classes will be namespace-less.
I'm inclined to use the directories they are in; so we have a
kde.kparts and a kde.kdeui kde.kdecore
where the last may be renamed to
kde.ui and kde.core

This is fairly normal naming in Java.

--
Thomas Zander

Boudewijn Rempt

2005-06-16 09:03:24 UTC

Post by Thomas Zander
Remembering a conversation on kdecore-devel about namespaces; the
consensus was that kdelibs was not going to be adding namespaces, meaning
most classes will be namespace-less.
I'm inclined to use the directories they are in; so we have a
kde.kparts and a kde.kdeui kde.kdecore
where the last may be renamed to
kde.ui and kde.core

I think that would be a good idea. Of course, this is from someone who was
innocent enough to make deep directory structures for his C++ packages when
he first started hacking in C++ a year and a half ago :-).

--
Boudewijn Rempt
http://www.valdyas.org/fading/index.cgi

Martijn Klingens

2005-06-16 09:16:16 UTC

That's only true for the 'old' parts of kdelibs like kdeui and kdecore.
KParts is already namespaced, KIO was 50/50 and will become fully
namespaced in KDE 4. I'm not sure for new code whether it HAS to be
namespaced or if there's just a strong preference for namespaces. Either
way, assuming kdelibs to be non-namespaced is wrong.

--
Martijn

David Goodenough

2005-06-16 09:59:49 UTC

So we use the namespace if it is specified, and directory if the namespace
is not available, and if all else fails we have a default which can either be
static or derived from some rule such as the what-is-the-first-letter rule.

David

Richard Dale

2005-06-16 09:20:38 UTC

Post by David Goodenough

Post by Thomas Zander
Remembering a conversation on kdecore-devel about namespaces; the
consensus was that kdelibs was not going to be adding namespaces,
meaning most classes will be namespace-less.
I'm inclined to use the directories they are in; so we have a
kde.kparts and a kde.kdeui kde.kdecore
where the last may be renamed to
kde.ui and kde.core

So we use the namespace if it is specified, and directory if the namespace
is not available, and if all else fails we have a default which can either
be static or derived from some rule such as the what-is-the-first-letter
rule.

Yes, and maybe some manual config file to override that if all else fails
(that might only be needed if you want to create bindings for your own
classes). The Qt4 headers are in subdirectories so we'll know where they came
from, and which java package to map onto.

-- Richard

David Goodenough

2005-06-16 10:39:18 UTC

Post by David Goodenough

Post by Thomas Zander
Remembering a conversation on kdecore-devel about namespaces; the
consensus was that kdelibs was not going to be adding namespaces,
meaning most classes will be namespace-less.
I'm inclined to use the directories they are in; so we have a
kde.kparts and a kde.kdeui kde.kdecore
where the last may be renamed to
kde.ui and kde.core

That's only true for the 'old' parts of kdelibs like kdeui and kdecore.
KParts is already namespaced, KIO was 50/50 and will become fully
namespaced in KDE 4. I'm not sure for new code whether it HAS to be
namespaced or if there's just a strong preference for namespaces.
Either way, assuming kdelibs to be non-namespaced is wrong.

So we use the namespace if it is specified, and directory if the
namespace is not available, and if all else fails we have a default which
can either be static or derived from some rule such as the
what-is-the-first-letter rule.

Well if the rule came from a script it would be easy to add fallbacks and
the scripts could be stored with the code and thus be "library" specific. The
scripts could also handle corner cases such as the directory being called
kde.kdecore and the package being kde.core.

David

Post by Richard Dale
-- Richard
_______________________________________________
Kde-java mailing list
https://mail.kde.org/mailman/listinfo/kde-java

Thomas Zander

2005-06-16 10:48:40 UTC

Post by Thomas Zander
Remembering a conversation on kdecore-devel about namespaces; the
consensus was that kdelibs was not going to be adding namespaces,
meaning most classes will be namespace-less.
I'm inclined to use the directories they are in; so we have a
kde.kparts and a kde.kdeui kde.kdecore
where the last may be renamed to
kde.ui and kde.core

That's only true for the 'old' parts of kdelibs like kdeui and kdecore.
KParts is already namespaced, KIO was 50/50 and will become fully
namespaced in KDE 4. I'm not sure for new code whether it HAS to be
namespaced or if there's just a strong preference for namespaces.
Either way, assuming kdelibs to be non-namespaced is wrong.

Well; I was making a point that the kdelibs was not designed around
namespaces very well. Badly designed and half finished is possibly worse
then not being namespaced IMO.

Next to that; Java packages and C++ namespaces are used in different
manners which lead C++ people to create huge namespaces and shallow
trees, exactly the opposite of Java people.
I'm still inclined to do the packages like I proposed before; based on
which dir they are in currently. With classes that may be moved
specified using regexps in a config file.

Continuing th use the "If it starts with a Q" seems wrong to me; we need a
build-script to call the converter and move the intelligence of which
package we are in to that build script. So the creator of Java classes
would be called multiple times, with different arguments. Any other
place to place that logic would seem out of scope IMO.

--
Thomas Zander

Richard Dale

2005-06-16 09:56:41 UTC

Post by Thomas Zander
Remembering a conversation on kdecore-devel about namespaces; the
consensus was that kdelibs was not going to be adding namespaces,
meaning most classes will be namespace-less.
I'm inclined to use the directories they are in; so we have a
kde.kparts and a kde.kdeui kde.kdecore
where the last may be renamed to
kde.ui and kde.core

That's only true for the 'old' parts of kdelibs like kdeui and kdecore.
KParts is already namespaced, KIO was 50/50 and will become fully
namespaced in KDE 4. I'm not sure for new code whether it HAS to be
namespaced or if there's just a strong preference for namespaces.
Either way, assuming kdelibs to be non-namespaced is wrong.

Yes, ok we could just ignore C++ namespaces and base it entirely on the
directory the include file is in for a class.

Post by Thomas Zander
Continuing th use the "If it starts with a Q" seems wrong to me; we need a
build-script to call the converter and move the intelligence of which
package we are in to that build script. So the creator of Java classes
would be called multiple times, with different arguments. Any other
place to place that logic would seem out of scope IMO.

Yes, we can generate code to load HashMaps with C++ classname <--> java
package/classnames mappings to use at runtime, instead of the "if it starts
with a Q" test. For instance, that's what the qtruby bindings do at startup.

-- Richard

Martijn Klingens

2005-06-16 11:20:19 UTC

Post by Thomas Zander
Next to that; Java packages and C++ namespaces are used in different
manners which lead C++ people to create huge namespaces and shallow
trees, exactly the opposite of Java people.
I'm still inclined to do the packages like I proposed before; based on
which dir they are in currently. With classes that may be moved
specified using regexps in a config file.

Yes, ok we could just ignore C++ namespaces and base it entirely on the
directory the include file is in for a class.

I don't think that's a good idea at all.

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.

Therefore the original API is leading and the other language will need to
follow. Anything else makes porting code harder, makes api docs
inconsistent, makes copy-pasting examples a pain, etc.

While I agree that it will make the KDE APIs look a bit awkward in a Java
ecosystem, so be it. When the bindings gain in popularity there will also
come C++ code with awkward-looking code due to imported Java APIs. Still
better than mappings that are non-obvious.

In that light I'm even hesitant to split Qt into QtCore and QtNetwork
etc., or even KDE into kde.core and kde.ui, since those also don't map all
that well to the existing usage and API.

--
Martijn

Thomas Zander

2005-06-16 11:44:40 UTC

Post by Thomas Zander
Next to that; Java packages and C++ namespaces are used in different
manners which lead C++ people to create huge namespaces and shallow
trees, exactly the opposite of Java people.
I'm still inclined to do the packages like I proposed before; based
on which dir they are in currently. With classes that may be moved
specified using regexps in a config file.

Yes, ok we could just ignore C++ namespaces and base it entirely on
the directory the include file is in for a class.

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.

Post by Martijn Klingens
Therefore the original API is leading and the other language will need
to follow. Anything else makes porting code harder,

porting?

Post by Martijn Klingens
makes api docs inconsistent,

They are copied into the binding classes, so this is not true.

Post by Martijn Klingens
makes copy-pasting examples a pain, etc.

Copy pasting C++ code to a Java program will not work anyway; and imports
v.s using are so different that this will fail anyway.

Post by Martijn Klingens
While I agree that it will make the KDE APIs look a bit awkward in a
Java ecosystem, so be it.

You are awfully quick to throw a huge benefit out the door. How convinced
are you that C++ coders will start to program Java any time soon? Using
their knowledge of the kdelibs API and expect it to be there in Java?

I'll tell you what my expectation is on that front; almost no C++ coder
will 'switch'.

Post by Martijn Klingens
When the bindings gain in popularity there
will also come C++ code with awkward-looking code due to imported Java
APIs. Still better than mappings that are non-obvious.

Here you are wrong; no Java programmer will reference the C++ code
examples or books or API docs. They are useless for those programmers,
as Qt is build on macros and various dirty tricks working around the
problems in C++, no Java programmer will understand such things.
So your claim goes out the window since there will be virtually no Java
programmers that are interrested in knowing the mappings in the first
place.

Post by Martijn Klingens
In that light I'm even hesitant to split Qt into QtCore and QtNetwork
etc., or even KDE into kde.core and kde.ui, since those also don't map
all that well to the existing usage and API.

Why is existing usage relevant?

--
Thomas Zander

Martijn Klingens

2005-06-16 12:33:32 UTC

Post by Thomas Zander
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.

Adding stuff is fine, changing existing stuff is not. The reason is that
if you need to solve problem X there are tons of pages in Google, on
developer.kde.org and wherenot that reference C++ code. It's a shame if
you can't easily adapt all that knowledge onto an other language.

That reminds me too much of when I was programming Delphi code in the old
days, most of the examples that you could find were either in Visual Basic
or in C using winapi, neither of which were easily converted to Delphi
code.

Likewise, I don't think Microsoft has its C# API fundamentally different
from VB.net or C++.net. that would be a similar problem.

For all practical purposes a clean API is not as important as being able
to leverage existing code and documentation IMNSHO.

(Snipping the rest of your mail as my reply would basically boil down to
this. As for me assuming C++ developers will switch to Java, I didn't even
really consider that optionn yet, what made you think I was after that
goal?)

--
Martijn

Thomas Zander

2005-06-16 13:40:36 UTC

Post by Martijn Klingens
For all practical purposes a clean API is not as important as being
able to leverage existing code and documentation IMNSHO.

KDE is not the only API any Java programmer would be using; you know. The
majority of the API would be the java.* and the javax.* stuff.
Being consistent with that is what will make this library easy to learn.

Leverage existing docs or code is meant to say you expect people to copy
paste C++ code and adapt that to Java?
In that case you should probably try programming Java for some 6months
since C++ is really different enough to not make that worth your while.
Unless you want to answer questions like: "How do I do a
macro/preprocessor/whatever in Java?"

Anyway; just moving classes to other packages is really not going to make
this stuff incompatible or whatever; java IDEs will autodetect package
and add it in your java file fully automatic anyway.

--
Thomas Zander

Richard Dale

2005-06-16 14:04:59 UTC

Post by Martijn Klingens
For all practical purposes a clean API is not as important as being
able to leverage existing code and documentation IMNSHO.

KDE is not the only API any Java programmer would be using; you know. The
majority of the API would be the java.* and the javax.* stuff.
Being consistent with that is what will make this library easy to learn.
Leverage existing docs or code is meant to say you expect people to copy
paste C++ code and adapt that to Java?
In that case you should probably try programming Java for some 6months
since C++ is really different enough to not make that worth your while.
Unless you want to answer questions like: "How do I do a
macro/preprocessor/whatever in Java?"
Anyway; just moving classes to other packages is really not going to make
this stuff incompatible or whatever; java IDEs will autodetect package
and add it in your java file fully automatic anyway.

My main concern is to fix the existing problem with the Qt/KDE java bindings
all being in only two packages, and the runtime doing a hack like 'does it
the classname start with K or Q tests'. So how that is solved isn't so
important to me, and technically changing the code generation to be driven
off namespaces as against include file directories is easy. Nobody has said
they like the existing scheme of 'org.kde.qt.QWidget' and that either
'qt.QWidget' or 'qt.gui.QWidget' would both be better. In ruby that would be
'Qt::Widget' and it is based on the C++ namespaces, not the include
directory. Nobody on the kdejava list has said that 'qt.Widget' looks good
so far.

-- Richard

Richard Dale

2005-06-17 08:44:37 UTC

Post by Martijn Klingens
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.

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 ***@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

Thomas Zander

2005-06-17 10:19:24 UTC

Post by Richard Dale
Have you seen this comparison between the java-gnome bindings and the
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.

Signal/slot is a technology that requires a pre-compiler due to lack of
introspection in C++.
In Java the introspection is there and it can be done, except that the
SLOT() syntax with a function name in there is not possible since thats a
macro.
Whats left is the option to type the method name as a string and on
connection find out which method that is.
Signals; however are completely impossible in Java the way they are done
in Qt. You need event broadcasters for that. an 'emit' keyword is
unavailable.

I created a signal/slot equivalent in an open source Java framework since
I was so frustrated by the standard way Java does things. its a best of
both worlds solution that probably would be nice to use in the bindings
as well.
see:
http://uic.sf.net/api/20/uic/action/package-summary.html

The framework is very mature (been in use for years) and has features like
multi-threading queues, action-locking and UI locking (sleepy pointer)
for actions running in another thread, and much more.

--
Thomas Zander

Richard Dale

2005-06-17 09:41:38 UTC

Signal/slot is a technology that requires a pre-compiler due to lack of
introspection in C++.

Well, no language binding needs a pre-processor; python, ruby, java, perl all
solve that problem in different ways. You can create a QMetaObject at
runtime, instead of at moc generation time for instance. QtJava doesn't do
that, but it is possible.

Post by Thomas Zander
In Java the introspection is there and it can be done, except that the
SLOT() syntax with a function name in there is not possible since thats a
macro.
Whats left is the option to type the method name as a string and on
connection find out which method that is.

Yes, that's right.

Post by Thomas Zander
Signals; however are completely impossible in Java the way they are done
in Qt. You need event broadcasters for that. an 'emit' keyword is
unavailable.

Well, have you looked at some code with slots/signals in QtJava? From the
ScribbleWindow example:

QObject.connect( _colormenu, SIGNAL( "activated( int )" ),
this, SLOT( "slotColorMenu( int )" ) );
...

QObject.connect( this, SIGNAL( "colorChanged( QColor )" ),
_scribblearea, SLOT( "setColor( QColor )" ) );
...

private void slotColorMenu( int item )
{
switch( item )
{
case COLOR_MENU_ID_BLACK:
emit("colorChanged", black());
break;
case COLOR_MENU_ID_RED:
emit("colorChanged", darkRed());
break;
case COLOR_MENU_ID_BLUE:
emit("colorChanged", darkBlue());
break;
case COLOR_MENU_ID_GREEN:
emit("colorChanged", darkGreen());
break;
case COLOR_MENU_ID_YELLOW:
emit("colorChanged", yellow());
break;
}
}

In the first connect statement, SIGNAL("activated(int)") is a C++ signal, and
in the second SIGNAL( "colorChanged( QColor )") is a java signal. They have
the same syntax. emit() is not type safe and I do have a better idea for
QtJava v2 using dynamic proxies. Note that interfaces for signals are
generated like this for QPopupMenuSignals.java looks like this:

//Auto-generated by kalyptus. DO NOT EDIT.
package org.kde.qt;

public interface QPopupMenuSignals {
void activated(int itemId);
void highlighted(int itemId);
void activatedRedirect(int itemId);
void highlightedRedirect(int itemId);
void aboutToShow();
void aboutToHide();
}

Post by Thomas Zander
I created a signal/slot equivalent in an open source Java framework since
I was so frustrated by the standard way Java does things. its a best of
both worlds solution that probably would be nice to use in the bindings
as well.
http://uic.sf.net/api/20/uic/action/package-summary.html
The framework is very mature (been in use for years) and has features like
multi-threading queues, action-locking and UI locking (sleepy pointer)
for actions running in another thread, and much more.

The slots/signals implementation in QtJava is mature too, and works fine,
integrating seamlessly with the C++ slots/signals in the Qt and KDE classes.

-- Richard

Richard Dale

2005-06-18 09:14:01 UTC

Post by Thomas Zander
I created a signal/slot equivalent in an open source Java framework since
I was so frustrated by the standard way Java does things.

Does this mean you don't like event listeners?

Post by Thomas Zander
its a best of
both worlds solution that probably would be nice to use in the bindings
as well.
http://uic.sf.net/api/20/uic/action/package-summary.html
The framework is very mature (been in use for years) and has features
like multi-threading queues, action-locking and UI locking (sleepy
pointer) for actions running in another thread, and much more.

The slots/signals implementation in QtJava is mature too, and works fine,
integrating seamlessly with the C++ slots/signals in the Qt and KDE classes.

Sorry if I sound a bit rude here, I didn't intend to kill the design
discussion stone dead. Is there some way of combining the best bits of the
two approaches?

-- Richard

Thomas Zander

2005-06-18 10:56:05 UTC

Post by Thomas Zander
I created a signal/slot equivalent in an open source Java framework
since I was so frustrated by the standard way Java does things.

Does this mean you don't like event listeners?

Thats right; having lots of inner classes make it really hard to reuse
stuff and really ugly to maintain.

Post by Thomas Zander
its a best of
both worlds solution that probably would be nice to use in the
bindings as well.
http://uic.sf.net/api/20/uic/action/package-summary.html
The framework is very mature (been in use for years) and has
features like multi-threading queues, action-locking and UI locking
(sleepy pointer) for actions running in another thread, and much
more.

The slots/signals implementation in QtJava is mature too, and works
fine, integrating seamlessly with the C++ slots/signals in the Qt and
KDE classes.

Sorry if I sound a bit rude here, I didn't intend to kill the design
discussion stone dead. Is there some way of combining the best bits of
the two approaches?

I made the suggestion not because I don't like the QtJava approuch, I have
not been able to compile kdebindngs yet, so I don't know.
My main concern is that its incompatible with Java proper meaning the user
has to use two different ways to do event connection in his programming
if he is to use any part of Java that does event -based messaging
together with the KDE libs.

I do have to admit that the syntax looked quite un-java to me as well.
Having emit() and SLOT() methods without a class scope in front it makes
me uneasy.

I feel its very important to make the bindings be just another library the
Java programmer will want to use, which therefor has to fit in design and
usage with all the other libraries of Java. It may not be obvious so
I'll mark it explicitly here; programming KDE Java means your app will
likely be 2/3th Java and 1/3 KDE based.

--
Thomas Zander

Richard Dale

2005-06-19 20:35:38 UTC

Post by Thomas Zander
I created a signal/slot equivalent in an open source Java framework
since I was so frustrated by the standard way Java does things.

Does this mean you don't like event listeners?

Thats right; having lots of inner classes make it really hard to reuse
stuff and really ugly to maintain.

Ok good we can leave them out of qtjava.

Post by Thomas Zander
its a best of
both worlds solution that probably would be nice to use in the
bindings as well.
http://uic.sf.net/api/20/uic/action/package-summary.html
The framework is very mature (been in use for years) and has
features like multi-threading queues, action-locking and UI locking
(sleepy pointer) for actions running in another thread, and much
more.

The slots/signals implementation in QtJava is mature too, and works
fine, integrating seamlessly with the C++ slots/signals in the Qt and
KDE classes.

Sorry if I sound a bit rude here, I didn't intend to kill the design
discussion stone dead. Is there some way of combining the best bits of
the two approaches?

I made the suggestion not because I don't like the QtJava approuch, I have
not been able to compile kdebindngs yet, so I don't know.
My main concern is that its incompatible with Java proper meaning the user
has to use two different ways to do event connection in his programming
if he is to use any part of Java that does event -based messaging
together with the KDE libs.
I do have to admit that the syntax looked quite un-java to me as well.
Having emit() and SLOT() methods without a class scope in front it makes
me uneasy.
I feel its very important to make the bindings be just another library the
Java programmer will want to use, which therefor has to fit in design and
usage with all the other libraries of Java. It may not be obvious so
I'll mark it explicitly here; programming KDE Java means your app will
likely be 2/3th Java and 1/3 KDE based.

I've got the same problem in qtruby, where the slots/signals are modeled quite
closely on the C++ api and look a bit ugly and un-rubylike. So I was thinking
of adding an alternative as well. On the other hand, I think it's useful to
have an option close to the C++ api to make it easy to convert code from C++
to java. But if you were starting from scratch, you might want to use the
version based on your design if it looked better. As long as the
implementation underneath is the same and compatible.

-- Richard

Thomas Zander

2005-06-20 08:13:46 UTC

On Sunday 19 June 2005 22:35, Richard Dale wrote:
[snip signal/slot discussion]

Post by Richard Dale
On the other hand, I think it's useful to
have an option close to the C++ api to make it easy to convert code
from C++ to java.

Realistically; how many people will do that?
But ok, if the implementation is there, we can use it. No need to throw
work away.
I assume the example code you typed uses a base object QObject? Or how
does an object know the SLOT method in your Java example?

Post by Richard Dale
But if you were starting from scratch, you might want
to use the version based on your design if it looked better. As long as
the implementation underneath is the same and compatible.

Naturally.

--
Thomas Zander

Richard Dale

2005-06-20 07:46:55 UTC

Post by Thomas Zander
[snip signal/slot discussion]

Post by Richard Dale
On the other hand, I think it's useful to
have an option close to the C++ api to make it easy to convert code
from C++ to java.

Realistically; how many people will do that?

Pretty much eveyone, because nearly all the documentation for Qt and KDE is
C++ based, including the code snippets. I've found ruby or java programmers
who can't program in C++, can manage to read the docs though. They just need
to learn a few basics like a 'char *', 'QString' and 'QCString' are all
Strings in ruby or java.

Post by Thomas Zander
But ok, if the implementation is there, we can use it. No need to throw
work away.
I assume the example code you typed uses a base object QObject? Or how
does an object know the SLOT method in your Java example?

They're defined in Qt.java, which is a superclass of QObject.java:

/** Prepend a '2' to a signal string and remove any spaces */
public static String SIGNAL(String signal) {
return "2" + sqeezeOut(signal, ' ');
}

/** Prepend a '1' to a slot string and remove any spaces */
public static String SLOT(String slot) {
return "1" + sqeezeOut(slot, ' ');
}

emit() is defined in QObject.java:

public native void emit(String signal, Object[] args);

protected void emit(String signal) {
Object[] args = new Object[0];
emit("2" + signal.trim() + "()", args);
}

protected void emit(String signal, Object value) {
Object[] args = new Object[1];
args[0] = value;
emit("2" + signal.trim() + "(" + value.getClass().getName() + ")", args);
}
...

There are lots of different overloaded methods for the various arg types, and
just one native method that they all map onto.

I would like to change it to look like this:

protected Proxy emit();

There would be a version in each subclass of QObject. The interfaces supported
by the Proxy returned by emit() would be all the <classname>Signals.java
interfaces for the class and it's superclasses. QPopupMenu has a signals
interface like this:

public interface QPopupMenuSignals {
void activated(int itemId);
void highlighted(int itemId);
void activatedRedirect(int itemId);
void highlightedRedirect(int itemId);
void aboutToShow();
void aboutToHide();
}

So to emit a signal from a subclass of QPopupMenu, you would cast the Proxy to
the appropriate interface:

((QPopupMenuSignals) emit()).activate(3)

Instead of the signal name being a string, it is a method in an interface, and
the emit call is type safe and can be checked at compile time.

-- Richard

Richard Dale

2005-06-16 08:17:12 UTC

Post by Richard Dale
But the package names are hard coded - any classes beginning with 'Q' go into
org.kde.qt and all others go into org.kde.koala. So maybe when we decide on a
better package naming scheme, the bindings generator ought to allow
any Qt headers to be used for bindings generation and not just the
ones in the Qt and KDE libs. Maybe a configuration file is needed for
C++ classname to Java
package/classname mappings.

That looks fine to me, I prefer the shorter forms kde.ui and kde.core. Then
every KDE class which isn't in a namespace or subdirectory under the include
directory should just be in kde.*.

-- Richard

Richard Dale

2005-06-16 08:04:11 UTC

Yes, the sources for the Smoke library are generated when you type make in
smoke/qt or smoke/kde directories, and they don't need to be checked into the
svn. I've been meaning to do that for java for ages, but haven't got round to
it. It would certainly be nice for the next version of the bindings.

Post by Richard Dale
But the package names are hard coded - any classes beginning with 'Q' go into
org.kde.qt and all others go into org.kde.koala. So maybe when we decide on a
better package naming scheme, the bindings generator ought to allow any
Qt headers to be used for bindings generation and not just the ones in
the Qt and KDE libs. Maybe a configuration file is needed for C++
classname to Java
package/classname mappings.

I should have said to try your headers in the smoke/kde directory, and add
them to the kde_header_list in there, and run 'perl generate.pl' in that
directory. Maybe any kde classes in a namespace should use the scheme you
give above. Then have a configuration file to specify any exceptions to the
rule. The Qt4 classes aren't in namespaces, but I think the best mapping for
them is one java package per library - qt.core.* qt.gui.* qt.xml.* and so on.

-- Richard

Richard Dale

2005-06-15 12:16:37 UTC

I really don't know where
Java support is right now and what is still missing

...

Post by Richard Dale
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'.

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.

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.

Post by Thomas Zander
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.

Post by Thomas Zander
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.

Post by Thomas Zander
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.
namespace java {
class KAboutDialog public java::KDialogBase {
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);
}
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.

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.