In honor of the 4.4 release, we’d like to go through some of the new features you should look out for.
WebKit is an open source web browser engine which is the basis of, among other things, the Safari web browser on Mac OS X. The engine has been integrated in Qt, and is available to Qt Jambi programmers in the package
com.trolltech.qt.webkit. This means that you can easily integrate web content in your applications, and jump on the whole acronym-bandwagon by using AJAX methodology in your code. Håvard did a whole blog teasing this feature a while back, so instead of rewriting all that, we’ll just point you in the right direction. Benjamin wrote a blog a few days ago that goes into more detail, so take a look at that as well if you’re interested. On the WebKit Integration announcement page you’ll find lots more information, and some very cool videos that illustrate some of its awesome powers.
Qt and Qt Jambi 4.4 gets full-blown multimedia support through the Phonon framework adopted from KDE. This gives easy access to playing and manipulating movies and music in all the nice file formats for which the underlying media framework has codecs. The framework defaults to using Gstreamer (Linux), Microsoft DirectShow (Windows) and Quicktime (Mac OS X). There’s also this teaser blog about Qt Jambi and Phonon with an example for those interested.
New deployment system (Qt Jambi specific)
While we’ve always been recommending a .jar based deployment method, we’ve required people to build their own .jar files containing the necessary native libraries, and a meta-info approach to specifying which dependencies exists in a given project. This system has proven not only to be easy to misunderstand, but to have some fundemental flaws that could cause crashes and general discomfort if you did it wrong. In fact, in order to deploy previous versions on Mac, it was required that you were either Eskil, Gunnar, or someone with direct e-mail contact with either of us. In Qt Jambi 4.4 we’ve hopefully fixed this once and for all, by defining a default .jar based deployment system which avoids problems with mixing libraries and in which deploying to a different platform is as easy as replacing a single platform specific .jar file. In fact, if size is irrelevant, it’s possible to ship a single distribution of your application which will run on all platforms, as long as the platform .jar file for the given platform is in the class path when running the application.
If you are building from source and require extra libraries to be included, this can be achieved simply by editing the ant script.
JDBC support (Qt Jambi specific)
A drawback in our SQL framework in previous versions of Qt Jambi has been that you needed to have access to a Qt/C++ source distribution in order to use it. The reason was that we could not provide binaries that were compatible with all the different database drivers out there. In Qt Jambi 4.4 we support the Java DataBase Connectivity API which is the industry standard for database access in Java. This has been available on Trolltech Labs for a while, but now it has finally been integrated in Qt Jambi and is available in the
com.trolltech.qt.sql package. Gunnar wrote a blog about it back when it was put up on labs.
XML support has been greatly improved in Qt and Qt Jambi 4.4. An example for this is the added support for XQuery 1.0 and XPath 2.0. In Qt Jambi, it is available in the package
com.trolltech.qt.xmlpatterns. For more information, see Frans’s blogs about the C++ version of the API.
One of the greater challenges in terms of mapping C++ to Java was the Qt Concurrent framework. This is a set of classes and functions that will help you parallelize tasks (e.g. to optimize for multicore cpus) without having to worry about many of issues the ordinarily related to multithreaded programming. In C++ it uses a lot of very language specific constructs, like templates and function pointers, making it hard to automatically map the API to Java. Indeed, we had to write part of the bindings layer by hand, replacing the use of function pointers with interfaces instead. We also implemented support in the Qt Jambi Generator for mapping C++ template classes to Java’s generic classes (under certain conditions) in order to get the correct API for classes such as
QFuture. The underlying, generated code for binding this class uses a general, reference counting wrapper for
java.lang.Object where the Java API (and the original C++ API) uses a generic parameter. Since generics in Java is a static, syntactic mechanism, there is no need to worry about it in the JNI code.
There are many more changes in Qt Jambi 4.4, bug fixes and new features. In order to get an overview of them all, you should see both the change logs for Qt Jambi 4.4 and Qt 4.4 (which will be out when the release is final.) From the top of our heads, we can mention an enhanced network API, QMetaObject introspection for Java objects, and numerous improvements to Designer.
Gunnar and Eskil