>I thought java was slow because of the Virtual Machine...
Using a VM means several things. There is a startup time (short command line programs for example will be damn slow in comparison for that reason), there is some memory overhead (about 8mb) and it handles memory itself, which means that there is usually some ram lying around for future use.
Java used to be damn slow, but thats many years ago. Since 1.2 there is JIT (just-in-time compilation... thats "hotspot" nowadays) and it became faster which each release. With 1.6 there was a surprisingly big performance jump (too bad that it isnt really out yet).
Most swing apps feel sorta slow, because lazy inits are used all over the place, which makes everything a tad unresponsive. However, most gtk apps seem to behave worse than that.
Oh and applets... they also make look java rather bad. Most of em are 1.0/1.1 compatible and do silly things, which prevent hardware acceleration (still faster than flash tho). And then there is the vm startup, which totally lags the browser. Heh.
So yea, there are surely a few things which make java look slow and there is still that leftover prejudice from the interpreted days.
Java (or managed languages in general) isnt the one size fits all super hammer, but its pretty good for a broad selection of applications (emulation hasnt been a part of that so far). I mean sure it would be nice to have everything written in asm hardcore optimized for this cpu, but that isnt really realistic. You always need to find a good trade-off between performance and development time/maintainability/security.
My favorite example for java's being-good-enough-ness is oddlabs' game
tribal trouble. It even works just fine on a 500mhz machine with a gf2mx
