A Comparison of Qt and Java for Large-Scale, Industrial-Strength GUI Development

Here is an interesting paper for you to read: http://turing.iimas.unam.mx/~elena/PDI-Lic/qt-vs-java-whitepaper.pdf.
Just skimmed through it. The good thing is that it is based on research (numbers do not lie ;) ) and not just some anecdotal "evidence". My thoughts? If you are a computer scientist who really knows their stuff and can choose between C++ and Java for your next project - choose C++. If you are an entrepreneur or a manager - hire the best programmers and choose C++... or Python... or Python & C++... and Qt ;)... or use OpenLaszlo... or ZK... or whatever ;)...
BTW, if you are a Java (or C#) programmer interested in mastering C++ & Qt then here is a nice book for you, which, apart from introducing Qt, contains a chapter (well, an appendix really) entitled "Introduction to C++ for Java and C# Programmers":

C++ GUI Programming with Qt 4 (2nd Edition)

The best thing is that the book has been published under the Open Publication License so it can be also legally downloaded from the Internet.

But returning to the paper... if you don't feel like reading the whole then here are some interesting excerpts:

--
In conclusion: both research and practice contradict the claim that Java programmers achieve a higher programmer-efficiency than C++ programmers.


Both independent academic research and industrial experience demonstrate that the hype favouring Java is mostly unjustified, and that the C++/Qt combination is superior.


Research shows that in practice, garbage collection and other Java features, do not have a major influence on the programmer-efficiency. One of the classic software estimation models, Barry Boehm’s CoCoMo1 predicts the cost and schedule of a software project using cost drivers which take into account variables like the general experience of a programmers, the experience with the programming language in question, the targeted reliability of the program, etc. Boehm writes that the amount of effort per source statement was highly independent of the language level. Other research, for example, A method of programming measurement and estimation by C.E. Walston and C.P. Felix of IBM, points in the same direction.


This is also backed up by our own experience: if programmers can choose their favorite programming language (which is usually the one they have most experience of), programmers with the same level of experience (measured for example, in years of programming experience in general) achieve about the same programmer-efficiency.


Another interesting aspect that we noted (but which is not yet supported by any formal research) is that less experienced developers seem to achieve somewhat better results with Java, medium-experienced developers achieve about the same results with both programming languages, and experienced developers achieve better results with C++.


Again, Prechelt provides useful data. The amount of data he provides is huge, but he arrives at the conclusion that "a Java program must be expected to run at least 1.22 times as long as a C/C++ program". Note that he says at least; the average runtime of Java programs is even longer. Our own experience shows that Java programs tend to run about 2-3 times as long than their equivalent C/C++ programs for the same task. Not surprisingly, Java loses even more ground when the tasks are CPU-bound.

When it comes to programs with a graphical user interface, the increased latency of Java programs is worse than the runtime performance hit. Usability studies show that users do not care about whether a long running task takes, say, two or three minutes, but they do care when a program does not show an immediate reaction to their interaction, for example when they press a button. These studies show that the limit of what a user accepts before they consider a program to be "unresponsive" can be as little as 0.7 seconds.


Prechtelt provides figures which state that on average (...) and with a confidence of 80%, the Java programs consume at least 32 MB (or 297%) more memory than the C/C++ programs (...). In addition to the higher memory requirements, the garbage collection process itself requires processing power which is consequently not available to the actual application functionality, leading to slower overall runtimes.


When dealing with external programs and devices, for example, during I/O or when interacting with a database, it is usually desirable to close the file or database connection as soon as it is no longer required. Using C++’s destructors, this happens as soon as the programmer calls delete. In Java, closing may not occur until the next garbage collecting sweep, which at best may tie up resources unnecessarily, and at worst risks the open resources ending up in an inconsistent state.


The fact that Java programs keep memory blocks around longer than is strictly necessary is especially problematic for embedded devices where memory is often at a premium.


To sum up this discussion, we have found C++ to provide much better runtime- and memory-efficiency than Java, while having comparable programmer-efficiency.

VirtualBox - hibernation of a host system may cause problems

Your virtual machines may not resume properly after thawing (i.e. starting the system after hibernation) - problems with vboxdrv kernel module. Here is my script which solves this issue (most of you can just put it in /etc/pm/sleep.d/action_virtualbox). I use Debian GNU/Linux but the script should work perfectly with other distros as well (e.g. Ubuntu, Fedora or Suse). The script puts all VMs to sleep (saves their state) and stores information about the associated processes (X Window display, real uid) in a file and tries to resume all VMs upon thawing, running them with correct user/display combination.

Do not worry if you cannot see the whole script (i.e. it appears to be clipped) just select and copy it with your mouse (or make your browser window wider).

#!/bin/sh
# suspend virtual machines on hibernate and resume them on thaw

# a file for storing a list of running vms
RVF='/var/run/running_vms'

PATH=/sbin:/usr/sbin:/bin:/usr/bin

if [ ! -x $SCRIPT ]; then
      exit 0
fi

SELF=action_virtualbox
COMMAND=

# pm-action(8) -  
#
# On hibernate, suspend all running VMs to disk
# resume them on thaw.

case "${1}" in
      hibernate)
              # 1. get a list of processes for all running virtual machines
              # 2. for each list item extract a login name, vm uid and display and store them in $RVF file
              # 3. save state of each vm
              ps eax -o user,cmd|
              grep '\bVirtualBox\b.*--startvm\b'|
              grep -v '\bgrep\b'|
              sed 's/\(^\w*\b\).*--startvm\( [[:alnum:]-]*\b\).*\( DISPLAY=:[0-9.]*\).*\($\)/\1\2\3\4/'|
              awk -v rvf=$RVF '
                      BEGIN {system(">"rvf)}
                      {print "\nSuspending VM "$2" (user: "$1")";
                       system("su -c \47VBoxManage -q controlvm "$2" savestate\47 "$1);
                       print "Appending VM data to file "rvf".\n";
                       system("echo "$0">>"rvf)}'
              # \47 is the single quote (i.e. "'")
              ;;
      thaw)
              if [ ! -s $RVF ]
              then
                      echo "No virtual machines suspended at the last hibernate which haven't already been thawed, therefore nothing to thaw."
                      exit 0
              fi
              cat $RVF|awk '
                      {print "\nResuming VM "$2" (user: "$1"; "$3")";
                       system("su -c \47"$3" VBoxManage -q startvm "$2"\47 "$1)}'
              echo "\nAll thawed. Deleting $RVF."
              rm $RVF
              ;;
esac