Submitted by “Trolltech today released an initial technology preview of Qt Jambi to its commercial customers and the open source community for testing and feedback. Qt Jambi is a prototype technology that enables Java developers to utilize Qt.”
“Trolltech today released an initial technology preview of Qt Jambi to its commercial customers and the open source community for testing and feedback. Qt Jambi is a prototype technology that enables Java developers to utilize Qt.”
QT is a fantastic GUI toolkit. However, event though I quite like C++, more and more developers are preferring higher level, managed/garbage collected languages like Java and C#. So it behooves Trolltech to feature their tool kit with Java/GCJ.
I would think the two would go together well. QT gets a popular language implementation, and Java gets another attractive, viable GUI alternative.
Qt Jambi’s API is so much cleaner than the C++ API – it doesn’t even look like a port at all, especially the signal-slot handling methods.
Compare this C++ code:
connect(newAct, SIGNAL(triggered()), this, SLOT(newFile()));
To this Java code:
newAct.triggered.connect(this, “newFile()”);
Edited 2006-07-29 00:06
> and Java gets another attractive, viable GUI
> alternative.
Tell me the other one 🙂
> and Java gets another attractive, viable GUI
> alternative.
Tell me the other one 🙂
well “Swing” ?
And dont say its slow or difficult – because its not !
IMHO Java doesnt need QT as Swing is good enough. But the more choises we have the better.
<dream on>Maby KDE will adopt java after Gnome adopt mono.. <dream off>
IMHO Java doesnt need QT as Swing is good enough.
Well even if it’s good enough, it’s always room for something better. And comparing what you hear from developers working with Swing to what you hear from developers using Qt, I’d say it’s a need for it too. And if you consider the fact that Trolltech is a commercial company, and they would not have developed this if they did not think some customers would buy it. So they obviously think there is a need.
But the more choises we have the better.
True.
<dream on>Maby KDE will adopt java after Gnome adopt mono.. <dream off>
Perhaps it’s rather time to wake up. There has been stable and up to date Java support in KDE for years, since KDE 2.2 or 2.1. That the bindings have seen minimal use, I think is more an indication that Java programmers are not interrested and that the Qt/C++ combination are so powerfull that Java gives minimal gain. Perhaps if Sun had paid developers to write and hype KDE/Java applications it may have seen higher usage. It may be that the official Trolltech bindings and eventual KDE addons to those, will give rise to Java apps in KDE.
Edited 2006-07-29 14:52
Maby KDE will adopt java after Gnome adopt mono…
Perhaps it’s rather time to wake up. There has been stable and up to date Java support in KDE for years, since KDE 2.2 or 2.1. That the bindings have seen minimal use, I think is more an indication that Java programmers are not interrested and that the Qt/C++ combination are so powerfull that Java gives minimal gain.
I don’t get it… if there are already Java bindings for KDE, then what is this QT Jambi about? Can anyone who knows explain?
Anyway, KDE apps written in Java sounds good to me. Middle ground between Python and C++, could be useful for a certain class of applications. No Mono/.NET disputes either! I think this would be interesting not so much for Java programmers interested in KDE, but more about (potential) KDE programmers interested in Java/.NET kind of languages.
IMHO Java doesnt need QT as Swing is good enough. But the more choises we have the better.
Well, that’s your opinion. However, the reason why Trolltech has done so well is because of alternative cross platform GUI APIs like Swing.
Edited 2006-07-29 17:12
> Compare this C++ code:
> connect(newAct, SIGNAL(triggered()), this,
> SLOT(newFile()));
>
> To this Java code:
> newAct.triggered.connect(this, “newFile()”);
Yeah, the Java syntax is slightly nicer. I won’t call that critical though. The C++ equivalent is more to type, but also readable.
It looks like people in KDE are pretty much very excited by this news : http://planetkde.org/
Well, i don’t quite get it…why would any Java programmer want to use this? We already have two quite well working GUI APIs with Swing and SWT and i would like to claim that for every other feature in QT, there is at least some open source jar which is just as good. Therefore, the only argument left for Jambi is the right look and feel for Java applications in KDE. For this, i feel the Jambi approach is the wrong one: wouldn’t it make rather sense to solve the licensing issue and write/release an SWT-QT adapter? Maybe someone has other ideas why a Java programmer would want to use this?
We already have two quite well working GUI APIs with Swing and SWT…
Swing fits in extremely poorly into different platform environments, and this will take some time to put right. Swing also has a pretty convoluted API that doesn’t read well either. I don’t particularly want to see another action listener.
As for SWT, it fits slightly better into different platform environments but its main environment is Win32 – no question. The GTK port is a poor second, and the Mac support is way, way behind that. It takes an absolutely huge amount of effort to maintain SWT in the way that it has been designed to use native widgets on each platform, and you then have to try and replicate how each platform works so you can get an application to look and behave the same on each. That’s no mean feat, and it’s debatable whether it is reliable to do.
Have a look at Eclipse’s and SWT’s bugzilla. Unfortunately, Eclipse and SWT GUI development is really just another way of doing Windows programming. Sad, but with more than an ounce of truth to it.
Maybe someone has other ideas why a Java programmer would want to use this?
You get all the Java tools and libraries that you’ve been using for some time, whilst getting a GUI framework and other libraries that actually work.
Edited 2006-07-29 10:46
> We already have two quite well working GUI APIs
> with Swing and SWT
lol, that’s a good one. I can’t judge SWT, as I haven’t used it. People I talked to, said it’s not that good either. Well, I won’t judge without testing. But for Swing, UI-wise it’s ugly and doesn’t integrate with native application at all.
The API sucks badly. Just look at the layout managers. One more unusable than the other, with GridBagLayout as only one powerful enough, but also the one with the most unusable API.
Swing just makes simple things complicated, instead of following the principle “Make simple things simple, hard things possible”. GUIs written in Swing by your average java developer are unusable, inconsistent and ugly, as there are no sane defaults.
For example, why are there no sane margins and spacings set? Labels don’t support word wrap, toolbars can’t shrink, etc. pp.
> Maybe someone has other ideas why a Java programmer
> would want to use this?
Because Qt has a good API and integrates well in the environment it is used in.
Another thought:
The SWT and Swing APIs can be used without any royalty fees. How about Jambi? I like benz’s idea to have a SWT-QT adapter.
The SWT and Swing APIs can be used without any royalty fees. How about Jambi?
I would imagine that it would have the same dual licensing as the rest of Qt.
I like benz’s idea to have a SWT-QT adapter.
There is actually such a thing, and a Qt based Eclipse is a part of Websphere. However, IBM paid a lot of money for it.
Since an inapproriate non-GPL compatible license was chosen for SWT (and there was no reason for that to be done), that’s not going to happen – at least not directly. I suppose the only other way would be better integration of GTK into Qt. However, since the GTK port of SWT is poor anyway……
Therefore, the only argument left for Jambi is the right look and feel for Java applications in KDE. For this, i feel the Jambi approach is the wrong one: wouldn’t it make rather sense to solve the licensing issue and write/release an SWT-QT adapter?
It must be more than a licencing issue, since at least Qt3 on Unix/X11 is also licenced unter QPL which would allow a SWT implementation, yet nobody has ever written one.
Then again, I guess the main target audience of Jambi will be embedded developers who have devices with Qt/embedded and Java VMs, who can then have a native GUI for their applications
I’ve programmed in Swing, Qt, and a little bit of SWT, and let me tell you, this is really good news.
At the moment, if you want to write a GUI app, the most high-level programming environment you can choose is C++/Qt. Between Boost smart pointers and Qt’s implicitly shared objects, you don’t have to do any memory management at all. Signals and slots are an order of magnitude easier to use than Swing-style callbacks. And finally, there’s Qt Designer; what free program exists that not only allows you to draw nice-looking forms visually, but also lets you import them into your program during runtime if you want?
The only “problem” with Qt that I can see is that it’s released under Trolltech’s usual license. Personally, I think this is awesome; it guarantees Trolltech’s financial success, which allows them to have a team of hackers working full-time to make Qt more awesome, and also keeps Qt accessible to open-source developers. Of course, many application developers might decide to use SWT or Swing instead to avoid paying the royalties or releasing their product under the GPL.
But in the end, that doesn’t really matter, since Trolltech’s business model is a proven success, and so anyone who wants to write a GUI app in the simplest way possible — and doesn’t mind releasing their code under the GPL — will always have this option.
I have to admit, I’m somewhat surprised my comment got rated up so highly, considering I forgot the second half of my post!
The release of Jambi makes Qt/Java far and away the best high-level GUI application framework. It has all the advantages of Qt/C++, with a few others that are only possible in Java:
* Guaranteed garbage collection. It is possible, through poor programming practice (such as not using smart pointers) to write a Qt/C++ program with memory leaks. In Java, that is not the case.
* No segfaults! When you’ve been programming in C++ for a while and you switch to Java, NullPointerExceptions make you very happy. They have a stack trace! They probably even tell you the exact variable which had the null value. This is invaluable for debugging.
* More standard. The STL is great, but has some problems (std::string does not have full Unicode support), which is why Qt invents its own classes. The Java equivalents are good enough. So Qt/Java programs can use standard Java container classes, which makes life much easier for projects that already have a substantial Java codebase.
* Even more crossplatform, but this goes without saying.
* If you’re being forced to use Java, you don’t have to settle for an inferior application framework. Or, to put it another way, if you have an existing Qt/C++ project and some manager decides that you need to port it to Java, you no longer need to port your application to a lower-level framework at the same time.
And finally:
* If this is successful, who’s to say that Trolltech won’t release their own bindings for an even higher-level language (Python or Ruby, perhaps)?
* Guaranteed garbage collection. It is possible, through poor programming practice (such as not using smart pointers) to write a Qt/C++ program with memory leaks. In Java, that is not the case.
That’s the same case in Java as well. It’s absolutely possible to introduce memory leaks through poor programming practice in Java as well.
I agree for the most part, but if you read the Jambi documentation (which is impressively complete for such an early release), Trolltech makes it very clear that not everything is garbage collected. Anytime that you’re using JNI to access native programs, garbage collection is anything but guaranteed.
Really, I don’t see Java as a competitor to C++ as much as I see it as competing with Ruby, Perl and other more dynamic but lower performing languages. Other things that Java has going for it (in addition to those mentioned above):
– No-brainer multi-threading (that’s native threads, meaning Java is already able to take advantage of multi-core and multi-cpu systems in a single program)
– Robust built-in database access (JDBC) and strong vendor support
– Solid networking libraries built into the JDK
– Syntax not too different from C++
– Strong security model
– Nice deployment model (with WebStart/JNLP)
– Great built-in documentation system in the form of Javadoc
– Reflection API
Plus, due to Java’s historical dominance in the server-side web application space, it benefits from a wealth of libraries (many open-source):
– All of the Jakarta Commons projects (like HttpClient)
– Robust networking and integration libraries and servers (SOAP/Web Services, JMS messaging, XML DOM/SAX/Pull APIs, MULE ESB, and the list goes on)
– The best (largely the only) RDF/OWL libraries
– Embeddable Http Servers (like Jetty)
– Distributed computing (JINI/JavaSpaces, EJB, CORBA)
– A top-notch free IDE in the form of Eclipse
– A ton of developers that have paying jobs doing Java programming
And I could go on …
For building the latest generation of web-connected applications, Java is without peers. Its achilles heel has always been a questionable UI framework, which Jambi may just fix.
>There has been stable and up to date Java support in
> KDE for years, since KDE 2.2 or 2.1.
Actually, the java support wasn’t that good, compared to e.g. ruby. Even the bindings author admits that (Richard Dale, the KDE binding god):
http://www.kdedevelopers.org/node/1557
http://www.kdedevelopers.org/node/2027
(Another one by Cies Breijs:)
http://ciesbreijs.blogspot.com/2005/11/kde-and-qtjava_13.html
> I don’t get it… if there are already Java
> bindings for KDE, then what is this QT Jambi about?
> Can anyone who knows explain?
Well, as pointed out by the blog entries I linked two postings before, QtJava never took off and even the author wasn’t satisfied with their quality. As there wasn’t that much interest and the author is more a ruby guy (he also maintains QtRuby), he didn’t spend too much time in improvement. Bindings in KDE is mainly done by Richard Dale, and his time is limited of course…
Java bindings maintained directly by trolltech will also please customers, so they can buy support from
Trolltech and there is a high chance for having good quality bindings supported by Trolltech in the long-term, being uptodate with the latest release.
Edited 2006-07-29 15:50
Java does not have free(), nor does it have delete. Therefore, no unreachable memory location will take up space.
You’re right that it is possible to have memory leaks in Java, by keeping references to unnecessary objects. Like NullPointerExceptions, however, it is much easier to solve a problem where you have information (in this case, the references) then when you have none. And anyway, this type of memory leak is possible in C++, too.
Old Swing was aweful. Every Java dev, and Sun will readily admit this. It was a slow memory hog, and the default metal theme look atrocious.
But with Java 1.4, and especially with Java 5, Swing has improved immensely. Metal looks a lot better, and Swing integrates Windows and MacOSX look and feel really weel. And Swing, if written properly, performs very well now. NetBeans looks and performs great, as does JAlbum, JDiskReport, JEdit, SQl developer and many other.
SWT is great. Some SWT apps that look great on both Windows and Linux/GTK/Gnome are Eclipse itself, Azureus, RSSOwl, and Eclipse Trader. I haven’t seen it on Mac, but it does the job fantastically on both Windows and Linux. And Eclipse RCP is fantastic. It provides a full runtime for swt/JFace, and the ability to creat different products for the the different platforms.
But all that said, the best GUI toolkit that I’ve encountered, including Win32/MFC/VB, GTK+, Swing, SWT, and QT, is, of course, QT. It is fast, looks awesome, it’s very easy to work with (amazing considering it’s in C++, which tends to be more complicated and difficult than higher level languages), and runs equally well on all the supported platforms.
So combine such an awesome GUI toolkit like QT with an awesome higher level, garbage collected, cross platform, huge API, powerful, ubiquitous, and high productivity language like Java, and you have a huge winner.
Jambi, if it takes off, might end up being the very best option for Java GUI development. It will also allow both Trolltech, and GPL and KDE development, to really benefit from the huge momentum, ubiquity, huge developer base of Java.
Talking about your Win-Win situations.
Guy Steele thinks Java is a competitor to C++:
And you’re right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren’t you happy?
Besides, Java is a competitor to C++ because anyone who would have written a C++ app 10 years ago will now consider Java, even if they don’t ultimately use it. (And, like you point out, the syntax is intentionally similar to C++, even in cases where Guy Steele surely knew that there was a better way to do it.)
I don’t think it’s fair to talk about JNI. Not only is it not garbage collected (whether or not you’re using Qt), but it’s not portable! That defeats the point for Java, and I doubt that many developers of Qt applications, most of whom are presumably using Qt because it’s easy, will jump at the chance to learn a hard API which will make their program non-cross-plaform.
1) Java is most certainly a competitor to C++ on the server, but not in the realm of thick-client desktop applications for everyday users (which is what we’re talking about here).
2) Sun tried to pitch portability as a black-and-white issue, which it just plain isn’t. QT (the C++ flavor) showed that it’s possible to write portable desktop applications for Windows, Linux and MacOS, using good-old C++. Adding Java bindings to QT isn’t going to make it any less cross-platform, even though these bindings use JNI.
1) Isn’t Eclipse a thick-client desktop application?
2) Unless I misunderstood the announcement, it is entirely possible to use Jambi without JNI. JNI is only necessary if you want to interface with existing C++ code. What I meant was that one of the large benefits of Qt/Java would be even better portability, and any application which made extensive use of JNI would not be able to use those benefits.
1) Yes
2) No, Jambi is built on top of Qt which is C++ so JNI is a must.
Jambi itself is written using JNI, but that doesn’t mean that a programmer who is only using standard Qt classes has to use JNI — and thus pay attention to memory management — himself.
Jambi itself is just a wrapper of Qt, since Qt is C++ they must use JNI to implement Jambi. If you use Jambi it doesnt mean that you will have to write JNI code but that’s what it’s using under the hood.
We agree completely then.
> Isn’t Eclipse a thick-client desktop application?
Yes, but Eclipse is, well, mainly a Java IDE.
Interestingly nearly all good Java desktop apps are used to write other Java apps. That’s a bit self-referential, isn’t it? 🙂