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.
You realize that JIT is inherently limited to a tiny bit of program which it compiles? JVM cannot spend neither time nor RAM building a whole program tree and making global optimizations like compilers can. And by the way, if you think that compilers are limited to static analysis only - there's also profile-guided optimization.
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.
In theory, it could do that. But if you do a reality check, you'll find out that JVMs right now are pretty mediocre compilers that lack even basic optimizations. Again, everything that JVM does, can be done by a compiler, but not vice versa. Compilers have nearly unlimited time and can spend gobs of RAM analyzing the program. They can use profile-guided optimization, allowing you to gather stats from a compiled program and then recompile it to better account for runtime behavior - if needed.
Oh, and while we're at it, fine-tuning assembly with specific CPU in mind does not matter these days except for SIMD ops. Waiting for memory accesses dominates CPU time - and here Java is at inherent disadvantage because you cannot really control memory layout of your data.
"Server software does not [need to] have single-thread performance because it's more often I/O bound - that means that CPU vendors can get away with CPUs like Bulldozer or SPARCs that suck at IPC (instruction per clock) performance."
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.
Before you call this nonsense, go read some analysis and check benchmarks.
"That's not a problem of Java, though, but all managed languages -
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
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
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:
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.
You probably don't remember that Vista (Longhorn back then) was supposed to be
Nowadays they are phasing away
"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.
C++ hits the sweet spot of being pretty high level (heard of meta-programming?) while also allowing you to go all the way down to assembly when needed. With Java or any other managed language, you are inherently limited by what JVM provides, and JVMs have more concerns to care about than runtime efficiency, so they will always offer some kind of trade-off - that's why I called them "generic". While you can probably fine-tune them within reason, you cannot find a JVM that would, say, completely disable all runtime checks because your specific app does not need them.
If you will ever need to code an application that has tight performance requirements, like being required to draw a complicated scene under 16 ms, you will understand what I am talking about better. So far you seem to be only looking at the boring side of programming