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

[Richard Dale]

On Thursday 16 June 2005 09:38, Martijn Klingens wrote:
> Richard Dale said:
> > 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.
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