* Java does JIT by default. This is going to do inlining, loop unwinding, etc. at runtime. You can help it do it’s job better if you know (and measure) what it’s doing.
* garbage collection may run at any time, and totally screw your performance. It is tunable though, and is fairly predictable with not a lot of work.
* a lot of slow Java apps are still a result of bad code – e.g. creating new Strings instead of using StringBuffer in a loop which may take arbitrarily large input data (this is a general pattern of not reusing objects). This is not only be way slower per-invocation but will also fill up memory and make the garbage collector work harder.

Wikipedia has a pretty decent article, actually – http://en.wikipedia.org/wiki/Java_performance

However, all that said, Java has some really decent profiling tools, and if you spend time optimizing your critical paths I don’t think that I/O errors (to take your OutputStream::write() example) are going to have a dramatic effect from VM version to version. There are tons of variables when you’re installing on systems that you don’t control, and it gets a lot worse when you’re talking cross-platform (and not just multiple versions, e.g. kernel for a particular OS).

If you want to make performance improvements, the important thing is to be able to measure the current state and continue to measure as you make changes (e.g. by profiling). The big problem with big C or C++ apps tends to be working around strange platform and toolchain quirks that cause undesirable problems, which having a VM somewhat shields you from as it becomes someone else’s problem :) This of course makes it harder for _you_ to solve, though; when you’re compiling the binary you can call a lot more of the shots (which is both good and bad of course).

I’m not really sure how to measure .net runtime versus java runtime performance. I would not be surprised if only supporting one OS and being able to focus on supporting it’s version-specific quirks was a lot more productive than what Sun is trying to do :) The way that you can call unmanaged code is much easier and faster in .net (P/Invoke) than in java (JNI), and .net obviously uses native UI elements so that’s probably going to help user perceived as well as actual performance right there.

I personally don’t think Java is a reasonable choice for desktop apps for a lot of reasons besides just performance (although that’s surely one). Others include the non-standard UI, lack of distribution channel, and cross-platform focus. .net surely pwns Java on all of these. I think that Java is still reasonable on the server side, but I don’t see how it can possibly compete on the client.