After several technical previews and betas, Trolltech has launched Qt Jambi (Qt for Java) as a product under a dual licensing model (commercial and GPL license). There are also some product information and demos, and downloads for open source versions.
This is cool in that it brings a modern programming language to Qt, in a fully supported way (a huge improvement over the Qt-Java bindings from what I understand).
One thing I’m really not clear on, though, is whether the end (Windows/Mac) user has to have something like a “Qt runtime” installed on their computer in order for the app to work. Or is it all built into the binary?
This depends on the way of application deployment.
If it is a normal Java application, it needs to either rely on JRE and Jambi being already installed, or it is bundling them in its installer.
If it is a Java WebStart application, the WebStart framework will take care of installing these dependencies.
From the application’s point of view and thuse the application developer’s and application user’s point of view it is just like any other Java application using an additional class library with native parts.
Thanks for the clarification.
Since you seem to be so knowledgeable, perhaps you could answer another question: Do regular (C++, native-compiled) Qt apps also need Qt installed on the (Windows/Mac) end user’s system?
Also, as someone else asked, what advantages might Qt Jambi bring to the average Java developer over Swing and SWT?
Do regular (C++, native-compiled) Qt apps also need Qt installed on the (Windows/Mac) end user’s system?
No, neither Qt nor Qt Jambi requires this. Native libraries are usually bundled with the application, whether it’s a Java application or a native application.
Also, as someone else asked, what advantages might Qt Jambi bring to the average Java developer over Swing and SWT?
Main points would be:
1. An API which we believe to be more intuitive, easy to learn, easy to read, with reasonable default behavior, and just plain more pleasant to use. This should be a big deal for people who do application development, as it allows them to focus on the tasks of their particular application, and not on battling the API they are using to develop it. In our experience, the alternatives out there have usability issues that Qt Jambi does not suffer from.
2. Professional support.
3. The ability to easily combine native and Java-code using Qt and Qt Jambi side-by-side, and using the Qt Jambi Generator, which is part of the package.
Thanks for the info. If you’ll bear with me, I have yet another couple of questions
:
Native libraries are usually bundled with the application, whether it’s a Java application or a native application.
Okay, so in the case of a Mac app I’d guess that the native libraries are bundled in the program’s app-folder, and in the case of Windows they’re bundled in an installation program?
The ability to easily combine native and Java-code using Qt and Qt Jambi side-by-side, and using the Qt Jambi Generator, which is part of the package.
That is cool. So if I understand correctly, the Generator (which sounds quite amazing by the way) is capable of letting you use C++ libraries in a Java project and compiling the thing to Java bytecode. But to avoid confusion, Qt Jambi does not work the other way around; i.e. you can’t integrate Java code into existing Qt projects and compile it all to a native platform, right?
No.
The generator makes it easier to interface with C++ classes from Java code. Java itself provides a mechanism called Java Native Interface (JNI) which basically maps methods of a Java class to C functions.
The generator uses this mechanism but hides all the ugly conversion code, e.g. converting Java variable types to C++/Qt variable types.
The JNI approach usually starts with a Java class and uses a generator to create the C function declarations.
The Jambi generator starts with a C++ class declaration (header file) and creates the correspinding Java class and the C/C++ glue code.
Lets for example say that you have your own Qt Widget class, some domain specific widget not available in the base Qt set.
You run the Jambi generator on it and it will more or less create Java bindings for your class, so you can then use it from Java, including the option of subclassing it in Java and overriding C++ virtual methods through Java methods.
Okay, thanks for clearing that up.
Yes, the libraries need to be present at application runtime, so they can either be installed separately or come bundled with the applications.
On Windows and Mac OSX the second option is usually preferred, though, similar to the Java Runtime Environment, it would be possible to install it only once into a system directory.
I am not sure this is the most usueful angle to look at it. I think the main question is: what advantages might Qt Jambi bring to the average Qt developer over C++
Examples would be:
– crossplatform IDE support through the Eclipse plugin
– huge number of Java utility libraries
– comparably trivial plugin handling (Class.forName vs. C based dlopen/dlsym)
I am not sure this is the most usueful angle to look at it. I think the main question is: what advantages might Qt Jambi bring to the average Qt developer over C++
You’re right, that is the angle I expect most people to look at it from. I just asked the question since I figured it was worth asking
.
but what I would like to know is how it compares to swing/swt/awt speedwise and in regards to native platform look and feel.
Of course, if you are a qt follower, no doubts, it is just what you were looking for. But for most of us already using one or other toolkit, what it brings to the table (other than consolidation, what, for sure, is pretty good) in the case it has similar shortcomings as of swing/swt/awt?
If it has other advantages/improvements over swing/swt/awt, I will sit and try to learn how to use it but, as everyone knows, toolkits now are really huge and demands lots of time to get used to and we need good reasons to shift to a new one.
Judging by the demo apps, the LnF is excellent; it picked up the widget style of my (skinned) Windows XP theme and everything.
When I started webstart demo, it’s single launcher application window consumed 105 megabytes of memory (displayed as “private bytes” in Process Explorer). Gotta love java technology
I currently have many other applications running and sorted by memory usage this demo is on the top of the list…
Java is quite memory hungry, but the webstart version of the demo will consume a lot more memory than when you download and run the demo manually. This is due to the fact that it unfortunately needs to load both Swing and Jambi in the same process.