So we reached another beta release of Qt Jambi, press release here.
This is, at least according to plans, the final beta before we release
the final version later this summer. The team has done a tremendous
job in improving this version from the previous and I’ll mention a few
things in detail later, but first of all, I’d like to mention that
this release is dual licensed.
Thats right! The beta2 version of Qt Jambi is released under the preview license
and also under the GPL license. We spent a some time getting this to
work together with Apache Harmony Open Source Java SE in addition to
the Sun JDK which we already had. For details on the law, look in the faq.
The GPLing includes both the library and the Qt Jambi Generator, and I
hope you’ll find this to be good news..
So what other things has happened since the last time… In the last
release we enabled object garbage collection for all objects, which
resulted in a number of reports from people that gui elements, like
toolbar buttins and menu items, were disappering. In this release we
introduced a reference counting scheme that should minimize the chance
for this happening…
We also got rid of most of the poorly named operator_Xxx functions and
tried to replace them with more intuitive functions. For instance
QDataStream.operator_shift_left(byte []) has become
QDataStream.writeBytes(byte []). The generator also detects a number
of operator== and operator which is used implement the equals()
function and the java.lang.Comparable interface.
The Eclipse integration has received several additions in making it
load a whole lot better. In fact on most systems you don’t need to set
-Djava.library.path anymore, Qt Jambi will just figure it out based on
the location of the qtjambi.jar file. In addition to that we also got
a new wizard for making custom widgets in Qt Designer from Eclipse.
There are a number of other things too, but this is turning into a
changelog and I didn’t want that, so just check it out. Here’s the
webstart:
I feel really good about this release, just look how exited we are…
Possibly related posts:
17 comments
Great work.
Very kickass toolkit.
I was very tired of C++
Nice to see its GPLd now! But I am getting a compile error on generator[1] with Qt 4.2.3 so I am guessing Qt 4.3 is required to compile?
[1] metainfogenerator.cpp:331: error: no matching function for call to ‘QHash::key(QFile*&, const char [1])’
/usr/qt/4/include/QtCore/qhash.h:610: note: candidates are: const Key QHash::key(const T&) const [with Key = QString, T = QFile*]
*** 1 errors, 4 warnings
What are the advantages of Qt Jambi over the SMOKE-based bindings in KDE? (apart from support from TrollTech)
perfect job !!!
I feel more and more less bad, porting our project from qt3.x / c++ to qtjambi / java
Why is the memory usage so big?
Java uses 30MB of memory on XP for simple QT dialog…
How can i reduce the memory usage?
cartman: Yes, Qt 4.3 snapshots are required to compile Qt Jambi. There should have been a clearer error message for this.
Pau Garcia i Quiles: I guess some major points would be: Qt Jambi is based on Qt 4, rather than Qt 3, and benefits from all the added functionality and improvements to the Qt API, and it will continue to benefit from future improvements to Qt. In addition, Qt Jambi is available under a dual license, while the KDE bindings for Java are only available under GPL as far as I know. Finally, Qt Jambi is actively being developed, which I believe development has stopped for the Qt/Java bindings in KDE.
David: Java in general is quite memory hungry. There is a small overhead per Qt Jambi object, and we are of course working on minimizing this overhead. To optimize memory usage in Java, one easy trick is to avoid relying on the garbage collector as much as possible. This can e.g. be done by reusing existing objects when it is possible.
I hope all this was helpful
Wow, you guys really need to lay off of the caffeine…
eskil:
SMOKE-based bindings for Java gave up with further development when Trolltech announced they were developing Java bindings, that is why there is no Qt4 version of those bindings. Therefore, the advantage of Qt Jambi over SMOKE-based bindings is the dual license (yes, QtJava was only GPL2).
I wonder if you are going to develop KDE-Java bindings like the ones we had in the times of QtJava.
Pau Garcia i Quiles: That’s a really unpleasant reply. And yea, given that there was exactly 0 usable applications developed with KDE Java bindings I can see how you must be upset…
Are you planning to develop an important KDE application in Java? If so then this post should be one of the best things you’ve heard in a long time – QtJambi is Free Software, go write the KDE bindings with the just open sourced generator and go nuts.
And as someone who seen and used both, the advantage of QtJambi isn’t dual license, at least not from the perspective of a Free Software purist – it’s the performance, maintenance and api. And no, KDE Java wasn’t even close to any of those things when stacked against QtJambi. The time that these guys spent performance tuning and making sure the api is nicely bridging Java and Qt api’s while staying intuitive for both groups can be counted in months.
But you know what? The whole point of all of this is that you can grab QtJambi, play with it and tell those guys what think.
I have got one question:
Will there be a plugin for Netbeans or only for Eclipse?
Netbeans has a C++-plugin, but I’m not sure about the licensing or if it’s usable as a starting point to develop a QtJambi plugin.
Thanks!
Steve
Thank you for GPL’ing the library, and especially the Qt Jambi Generator. Now, I’m eagerly awaiting “KDE Jambi”
Pau Garcia i Quiles : try to understand that this is the BEST thing for KDE. Now there’s need to maintain SMOKE and to port it on KDE4 (!), this will save a lot of efforts.
Zack:
I do not think my answer was unpleasant and I am/was not upset. On the other hand, I think your answer was quite impolite.
I just stated some facts: with SMOKE we had Qt-Java and KDE-Java bindings; with Jambi *for now* we only have Qt-Java bindings. I am not blaming anyone for the death of SMOKE-based Java bindings or saying QtJambi is useless or anything like that as you seem to think.
BTW, I only want the best of Qt and KDE, as they are my platform of choice both for work and home. No interest in flamewars.
Zack: I don’t think Pau was intending to be rude at all. I agree the KDE Java bindings were a bit of a failure and there were indeed roughly about 0 applications produced with them, and I hope that that QtJambi based KDE java bindings will be more successful.
I think it is an interesting question, whether or not it is possible to produce a language independent library that is as fast as a bindings library like QtJambi that is carefully tuned for a specific language. The Smoke based Qyoto C# bindings have a very thorough coverage of the Qt4 api, although there is not integration with C# threads like QtJambi has with Java threads. However, they are quite slow at present, and I suspect a Smoke based Qt Java binding would have been slow too.
Anyhow, congratulations on releasing the GPL’d version of QtJambi, and I hope it will lead people to thinking of Qt as a great cross-language api as well as a great cross-platform api.
>We spent a some time getting this to work together with Apache Harmony Open Source Java SE in addition to the Sun JDK which we already had.
Did you have any problems with Harmony?
If yes, feel free to file a bug here: http://issues.apache.org/jira/browse/HARMONY and I hope it will be fixed asap.
Great news, I’ll test this as soon as possible. Only a question, are there any plans to develop Qt for .net/Mono?
Raul: To answer your question about Qt for .net/Mono, we do mention this in the last part of the Whitepaper. Basically what it says is that we’ve now proven that language bindings of Qt can be done in a way that is efficient enough to do application development and if there is enough interest, then we’ll do it for other languages too. Right now there is no plans for CLR bindings, but a year or two from now that may have changed depending on the input we get.
Thanks for your answer Gunnar
Comments on this entry are closed.