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.

Feature	Qt/C++	Spring/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.
Widgets	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.
Performance	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	Horrible! 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.	Excellent! 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.

Conclusion

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.