No, I'm saying it performs as well as C++ in most cases. Virtual method handling is one example as to why, the JIT has a better view at execution time as to what can and can't be inlined, so it can inline much more than a statically compiled C++ program possibly can.

Well that's precisely the problem you face if you don't have an explosion of optimised binaries, unless you want to accept that the JVM is going to optimise more efficiently. It's not just about compiling for different architectures, it's about the JIT automatically being able to optimise to take advantage of extensions, and other hardware that may be present too. It can optimise dependent on amount of RAM, cache sizes etc. - something that just isn't known when you compile a plain old generic C++ binary for, say, the generic x86 platform.

But there are a number of other things it can do better too - better loop vectorisation (as a result of better inlining of virtual functions) and more efficient heap allocations for example.

This is nonsense. It depends entirely on the application. A heavy load web server for example may not really be I/O bound in the slightest depending on the size and what it does. Bulldozer is designed for optimisation of performance per watt, you're again confusing cause and effect as to why some things are the way they are.

Really, the problem is simply that you don't understand managed languages. Your understanding of the optimisations performed by JIT compilers is clearly woefully inadequate to being making this sort of comment. Your comments on server applications just don't even make sense for the most part to the point I'm not even sure you have the slightest grasp of what sort of things servers commonly serve.

"Microsoft tried to build an OS which would be .NET based - they wasted like 6 years on that and ultimately had to abandon the idea. Now they are going native :)"

This is just further nonsense. There was a Microsoft research project to try and build such a thing, and they did, and open sourced it. I don't know what you mean by "Now they are going native :)", they've always been native with their operating systems. If you were expecting their managed OS to cause them to throw out 3 decades of legacy code then you have a disturbing view of how software is developed.

It was a research project and nothing more, and even then it wasn't purely managed, they still had to bootstrap natively because no one ever pretended that managed languages are designed to do such low level operations. You can find out more about it here:

http://research.microsoft.com/en-us/projects/singularity/

It's worth noting though that some of the things learnt from this research project have already made their way into Windows, but that's kind of the point of research.

"Sure, when I'm forced to use Java (e.g. Android), I immediately use the JNI window to escape. I am not interested in "benefits" of Java, if it means that I need to waste even more time trying to profile the application."

Right, and most people wont be interested in the downsides of your approach either because it simply means you're producing software much more slowly and with more scope for fatal bugs and security vulnerabilities.

You sound like one of those developers who has his little comfort zone and just can't deal with change. Everything should be written in assembly like it used to be! This is telling from your lack of knowledge about both JIT technology and server side software and hardware.

Like it or not, times have changed, there are better ways of doing things now such that the window of cases where C and C++ are the best tool for the job is rapidly diminishing. They're not worthless, they still very much have their place - low level operating system development being one example, some embedded development cases being another. But the fact is these languages have no tangible benefits over their managed counterparts for most real world scenarios that exist today, whether that's building desktop applications, or creating dynamic web pages, or building HPC trading systems. They do however have a number of downsides - slower development cycle and less secure and more error prone development by default being the obvious ones.

You either need to get over your fear of change and learn a bit more about these sorts of technologies and understand why much of what you said is wrong, or just stick to what you know and shut up about things you don't. Either way, sticking to what you know and complaining about that you don't know just results in you spouting nonsense as you have thus far in this thread with your simply outright incorrect comments about JIT technologies and server applications and hardware.

It still drives down wages. [...] wages fall, maybe not ot third world levels, but below what the market would normally dictate.