Qt Jambi is all about breaking away the barriers between Qt in Java and Qt in C++. In fact, ideally you should be able to sit inside of either language and throw anything you want over to the other side, and somewhere along its parabolic path over the wall, this thing should magically transform to whatever the destination expects it to be. In that sense, Qt Jambi is kind of like Shakespeare futilely trying to marry a Capulet with a Montague (a plague o’ both your language designers!)

Definitely, there’s a lot of drama and tragedy involved, and there are certainly always things you can throw over that wall which anyone sitting on the other side will consider mysterious and meaningless. Most of the time, though (and the emphasis is very much on “most”) this works. Despite the many differences between the two programming languages, the APIs in Qt Jambi are almost identical to the C++ APIs, and, most importantly, the intention of the APIs is intact.

Right now, though, I want to focus on one thing which has so far not been supported: the Qt meta-object system. The meta-object system is an extension to C++ which adds introspection, dynamic method invocation and similar concepts to the language (which otherwise lacks any such features.) It is also the basis of the signals and slots inter-object communication mechanism which is featured heavily in both the Qt and Qt Jambi APIs.

We never implemented an equivalent of the meta-object system in Java. The main reason for this was, quite simply, that it wasn’t necessary. Java already has a more or less complete reflection API with all the meta-info you could ever ask for. Thus, we decided to implement signals and slots in Java on top of Java’s reflection API, and create a small binding layer in between which ensures the grittiest of the details work (emitting a signal in C++ emits the equivalent signal in Java etc.)

Still, we lacked one gritty detail: In some cases, Qt relies on introspecting objects through the meta-object system without going through the signals and slots mechanism. An example of this is when you register a mandatory field in a wizard. In this particular case, Qt Jambi currently does not support custom widgets as editors for the mandatory fields. There are very few places in Qt where this is actually relevant, but even so, in principle it’s a pretty big gap, so following our quest to fill as many holes as possible, in Qt Jambi 4.4 we will introduce the fake meta object.

As you can see from my illustration of what a screen shot of the fake meta-object would look like, if it was indeed possible to take a screen shot of it, it is not all that different from the regular meta-object. The main difference is that the fake meta-object is generated at run-time rather than be a statically compiled unit, and also that it may at some point rob a train using only dynamite and a hot air balloon. We generate the meta-object on request, and only once per class, and only for user subclasses, as all the C++ classes will already have proper meta-objects of their own. For compatibility with the general expectations Qt has to meta-objects, we also convert all Java signatures into C++ signatures before stuffing them into the fake meta-object. Of course, not all Java classes have C++ equivalents known to us (any class featured in the type system used to generate the Java code is handled automatically), in which case we use the JNI type jobject as a general fall back, meaning that you can potentially use this together with other JNI-based frameworks.

So, in conclusion: In Qt Jambi 4.4 you can, among other things, look forward to cool-looking beards and even more complete mappings of the Qt APIs. The fake meta-object also allows us to remove a bunch of hacky hacks e.g. to make Java classes blend in with Qt Designer (you don’t want to know) so expect it to give a general boost in stability and readability as well. We really like it, hope you will too.