[Kde-java] QtJava rewritten as a SMOKE adaptor?

[Richard Dale]

Hi Gert-Jan

On Friday 08 August 2003 11:05, Gert-Jan van der Heiden wrote:
> I've read about smoke a while ago:
> http://dot.kde.org/1032279318/
> http://developer.kde.org/language-bindings/smoke/index.html
> PerlQt is using it, it would be nice if more bindings would use the same
> library. If more bindings use the same library, you can guess the benefits.
Yes, it really does work well. The other benefit is that if Perl, Ruby and 
Java share the same runtime library it makes it possible to subclass virtual 
methods already overriden in another language. So you could write a KPart in 
java, and a Ruby program could subclass and load the part, overriding some of 
the virtual methods in ruby (in fact in ruby you don't even have to subclass 
to override methods, and you can do it on the fly).

> GCJ seems to implements the java.lang.reflect.Proxy class
> (http://gcc.gnu.org/java/jdk14-libgcj.html#pkg_java_lang_reflect). So
> compiling with GCJ shouldn't be a problem with the new SMOKE approach.
Yes, that's good news - I'm a real Proxy fan - and I've been keen to do 
something with them for a while. I don't likeJNI much at all - it's a 
nightmare to maintain unless you can autogenerate it.

> The Java / KDE bindings suffer from some dynamic casts problems. Does this
> SMOKE approach solve that problem too?
Yes, it does casts correctly, no matter what the inheritance heirarchy is. All 
that kind of thing is really well engineered.

> It sounds really good, a structural solution for all virtual methods and
> slot /signals. A true added value to the current Java/ KDE bindings.
Yes, and an easier DCOP implementation too! When we tried to add DCOP support 
earlier this year, the current way the bindings work just didn't fit. I just 
couldn't see a tidy way to do it. We would have needed a bazillion different 
methods called invoke() for all the possible argument type combinations. 

But SMOKE has a stack, you just convert the args from the bindings language to 
C++ on the Smoke::Stack (yes it is written like that!), and then invoke the 
target method with a single C++ method call. When we were discussing dynamic 
DCOP for QtRuby the other day on kdebindings, you could see how well it would 
just fall out, and could work in almost the same way that it invokes a normal 
method. 

With incoming DCOP calls, it would have to build a Smoke::Stack from the 
incoming args in C++, and then the marshalling code would convert those to 
java reflection style format and invoke the target java method.

> My only comment for now is that SMOKE isn't updated lately in CVS (6 months
> or so).
Ashley is currently rewriting the way the SMOKE library is generated - rather 
than have kalyptus parse headers to do it, he will use a tool to extract the 
info from the compiled code 'translation unit' which should be much more 
accurate, as well as only needing to be done once for all languages.

But I think it might be a good idea to carry on with the kalyptus header 
parsing method so we can get some KDE bindings for ruby and java done, using 
the SMOKE mk1 style libraries. I'm not sure what problems the PerlQt have had 
with doing that yet. The api of SMOKE mk 2 should be backwards compatible 
with SMOKE mk 1.

-- Richard