Wednesday, December 30, 2009

Qt/C++ Programming vs Spring/Java Development

After a few days with Qt and reunion with C++ (after almost 10 years), I have some thoughts about Qt and C++ development when compared to my experience with Spring and Java.

Memory management
Qt makes C++ more bearable by cleaning up child objects automatically if its parent is destroyed. But still far from what Java has to offer, new and forget. ;-)
Java is clear winner here. Furthermore, Spring makes object lifecycle ("beans") even more automatic and controlled. You can have singleton beans, prototype scoped beans, etc. And autowiring.
Dependency Injection
Aside from Qt's standard signals and slots, and Qt Designer for wiring widgets, there isn't much. Or maybe I haven't found it.
Qt is no match for Spring's powerful dependency injection capabilities, whether using XML configuration or (even more) annotations. It's not a Java feature, but it's not specific to Spring either. Other frameworks like Guice and JBoss Seam also have this feature, especially with the recent WebBeans aka Java Context and Dependency Injection (CDI) aka JSR-299.
Event Handling
Qt has standard signals and slots, which is superior when compared to traditional C/C++, or even Java for that matter. (now I realized what the fuss with signals and slots is all about!)
No support for free-form publish-subscribe event handling, only declared signals.
Java has Observer pattern, Listener pattern, and recently (thanks to OSGi) the Whiteboard pattern.
The closest to direct connection in Java is properties with interface types, a.k.a.:
private ActionListener clickListener;
Spring can help with wiring, which reliefs much of the pain.
Granted, all of them are inferior compared to Qt's signals and slots, with agreed conventions semi-message-passing capability (with QueueConnection and BlockingQueueConnection).
Surprisingly, even Dojo has dojo.connect which is very similar (if not exactly) like Qt's signals and slots and dojo.publish for free-form publish-subscribe messaging/event handling.
Fortunately, both techniques are trivially implemented in Java with help of an integration library such as Apache Camel or Spring Integration. This really needs to be part of core Java specs.
I guess this is the strength of Qt. I like it, and I like how it looks, especially with the new GTK+ style. Blends in with other Ubuntu apps.
I mainly develop web-based Spring apps with Dojo AJAX toolkit, not desktop ones, so I can't really compare. However, I've had some experience with Swing GUI and Eclipse RCP (SWT) apps. I can say Qt's feel smoother both visually and performance-wise.
Programming either Swing or SWT is more pleasant than Qt, due to Java.
Excellent. Both building and running.
Very good. Frankly, I don't think Java is that slow anymore. I haven't yet proven myself that Java apps can be faster than C++ counterparts, but I'm sure there are such cases.
Build & Dependency Management
Qt Creator and qmake did its job, but there's no dependency management, library hell, etc.
Dependencies must be compiled with their respective tooling, sometimes conflicting.
Real-life example: Qt Mobility 1.0 TP2 can't be compiled with GCC 4.4, needs GCC 4.3.
Pick your poison: Eclipse's, NetBeans', Maven, Ant + Ivy, or plain Ant. For some people, IntelliJ's.
Yes the tools are quite fragmented, but the most manual thing you needed to do upon tooling conflict is download the (binary! thank God!) dependencies manually and put them on correct locations.
Works on all platforms.


Overall, I'd say Spring/Java development is more enjoyable than Qt/C++ programming.

Java's lack of convenient event handling mechanism disturbs me. Although integration libraries cure that itch to some extent, most Java developers will code them manually. Besides, not every project uses integration libraries, or even if they do, they might use different libraries, leading to redundancy and other issues.


  1. Java development services with dedicated Java developers. Java development outsourcing with proficient Java Developers.

  2. Well, for heavyweight messaging cross JVM, JMS is a JEE standard, but really? signals and slots? I think the J2SE standard regards this as so trivial an implementation as to be unnecessary to include in the JDK, and with Generics/Templates it's pretty easy to make type safe. I mean it's like 20 lines of code to stick in a library some place and just pull in with Maven forever more. Then we can talk about AOP, a system that is a level above what signals and slots can do where you can essentially make signals/slots totally auto-wired using reflection and so much more.

  3. PlexQ: Doable? Yes. Trivial? I don't think so.

    These articles show much I tried to "copy" signals and slots to Java:


    Generics? Yes, see #3 above.

    While 20 lines of code may get you simple dispatch mechanism, it's not enough when you try to cover all the functionalities of Qt signals and slots (like asynchronous mechanism).

    I think you can use Groovy or Scala to make it easier, but that's cheating, since it's not portable.

    And all solutions I've tried involve a third-party library (in my cases, EventBus, Apache Camel, or Spring Integration) AND THEN some conventions. (I think an ad-hoc shared library, however small, is a worse alternative then using a popular library like Apache Camel)

    While in Qt, you get all this for "free", it's in Qt core, you can use with the default language (C++), standardized conventions.

    Note that I'm not comparing Qt to Java the language, I'm comparing Qt to Java 2 SE. Even I tried comparing Qt to Spring or Java EE... In the signals/slots department, Qt still wins.

    And don't forget the Java doesn't have "function pointers" like C++ does. You have to wrap it inside a class and two different classes containing the same method with the exact same signature are still two different classes.

    Groovy/Scala has function closures but... it's still cheating. ;)

  4. I found your website perfect for my needs. It contains wonderful and helpful posts. I have read most of them and got a lot from them

  5. Rize team of Java Developers have good experience and knowledge in Java application development.


Be the first to comment!