"WILL NEVER": gosh, not true and never has been unless you know the exact CPU and execution paths and data sets that you are compiling for, for all executions of the statically-compiled code. Please don't regurgitate this stuff.
When maintaining a C++ build system used internationally by a large bank I had to guess what the optimal target instruction set variant, cache line size, etc, would be over the lifetime of the output code, which was always a compromise over London/NYC/TOK/etc and a huge range of dev and production hosts of various ages. And with most/much of the library stack unsafe for C/C++ threading even though almost none of our machines (eg desktop or server-farm) where single CPU you could not then and could not now say whether C++ or Java would be necessarily faster on a given machine, given all the CPU- and run- specific optimisations the JVM has available to it that C++ does not.
I currently work on a Java low-latency high-frequency trading platform in the day job and an ASM/C/C++ based microcontroller platform for my start-up. And I think that I've been using C++ and Java for most of their existences, amongst other languages (I've been writing ASM for >30y); I have a fair idea of what is fast and what is productive.