C++ is a decent language if you know what you're doing. Think of it as a stallion, compared to Java's compliant mare. Sometimes you need to wrastle, but it always has the power. Oh, and while it will never refuse a jump, it might get both your necks broken when you fu.
AFA GUI toolkits go, Java's isn't all that platform independent. Forget having a consistent look, and the feel is sometimes a bit flexible (it may be possible to get around this by programming a L&F set of classes). Plus I don't really see why GTK couldn't be implemented under Windows; just get a great big drawable and take it from there.
BUT, in terms of distributing source it cuts down the time involved in porting the software. My C++ GUI
Also, compiling from source is a pain in the a**. Just incidentally, there _are_ Java decompilers out there and they do work fairly decently. The guy who taught Java to my year was new to the uni, and he set a rather difficult AWT/events assignment. So we knew what he wanted, he put an applet on the web.
I did code it myself, but it was very tempting to give him his own code to mark.
This is the similar run time compilation technique that is used with Jikes, it loads up the bytecode, converts to machine code, then executes it. In my experience, the speed penalty is usually involved in loading the associated class libraries for the JVM, rather that the bytecode translation (which is effectively a lookup table!)... I have read various article, reports and experiments which say that Java /can/ be almost as fast as native code, while other say the Java bytecode translation is a lot slower that native code.
It vastly depends on the JVM you use. If you benchmark Sun's 1.0 JVM, it is slow as heck. However, with the advent of HotSpot (from Sun) and MMI (from IBM, which is better), the JVM is able to analyse the bytecode and decide which bits are worth compiling to native. This gives performance near equal to C, and (wild unfounded guess) probably much better than any loose-typed or philosophy-designed language like PHP or Scheme.
Startup time for the JVM is a second or less for me, which is significant if you're doing something mad like one JVM per web request, but not if you're writing an application.
A friend does real time image processing, which involves a large number of calculations a second. In this case Java is too slow for what he needs to do. Another writes Java GUI's that control native code. As long as the GUI is quick enough to respond to the user there is no problem.
The issue here is 'fast enough' really. If your program is compute-bound then ultimately you'll be doing assembler. As Sz says, it's the IO that usually matters, and a decent JVM is fast enough for that.
Alexis