I started writing programs in Java in the early days in 1996. Back then, native code (compiled for a particular CPU and operating system) was faster than (Java) virtual machine code, but Java let you run your program across multiple platforms with having to tear your hair out, and that was sometimes more important than raw speed.
A few years later, people started to challenge the prevailing assumption that native code is faster. The thing is, if you have infinite time and resources to write your code, you can make a program faster by using native code. However, in the real world, no-one has that luxury. When things have to be done within budget, by a particular deadline, it changes things significantly.
With Java, you finished writing the code earlier. That gave you more time for testing, debugging, and performance optimisation. Mike Kay gave a great presentation at a conference on how virtual machines are delivering on performance. With native code, once it is compiled, that is it. It runs as fast as it runs. The only way it will run faster is if you move it onto faster hardware. With virtual machine code, it's different. Mike produces the Saxon XSLT engine, which is written in Java. He pointed out that with each new release of Java, the virtual machine gets faster. Your programs run faster, even on the same machine. This is because new optimisations can be introduced between the virtual machine code and the native code that is dynamically generated when Java runs. For XSLT stylesheets, you also get speed improvements as the XSLT engine is improved and optimised. So you have multiple layers of optimisation that are making your programs faster and faster, without your having to change them.
But, does this really work in practice? I have to admit, I expected Java programs to eventually be fast enough that the extra speed of native code wasn't worth the trouble. Yesterday my limited expectations were blown out of the water. I was doing a small XML task, regrouping the information in a document into a different structure. When I do XML to XML transformations, I usually use XSLT, because it's the quickest and most straightforward thing to write. XSLT 2.0 makes it easier to do grouping transformations than XSLT 1.0, so I was using XML Spy 2005 to write and run a suitable XSLT 2.0 transformation. Eventually, though, I found a bug in Spy's implementation of grouping functions (specifically, "current-group()" returned an empty sequence even when "current-group()" was non-empty).
I switched to my laptop where I have the oXygen XML/XSLT editor, which is written in Java. I selected Saxon 8B as the XSLT 2.0 engine. It ran the the stylesheet correctly, but more importantly, it ran at least ten times faster than the native code implementation in XML Spy. Now, that is something I wasn't expecting. This is the first time where I have seen a huge performance boost by moving from a native code solution to a Java solution.
What does this all mean? Well, I'm not suggesting that Java programs are always faster now than their native code equivalents. That isn't the case. What I am suggesting is that it is no longer valid to assume that native code solutions are faster than Java (or other virtual machine) solutions. Some solutions will be faster than others, but you won't know if native code is faster or slower than virtual machine code now without actually testing it. That is a significant change, which impacts the way architectural technology choices are made for projects.
By the way, in XML Spy's defense, it's XML diff tool handles much larger documents than oXygen's without running out of memory. The native code solutions aren't going away. It's just that they can no longer claim an automatic performance advantage.