Urban legends tend to live forever.
In fact, I have asked a number of people under the impression that Java is slow to explain why they think it is slow. The answers have two flavors:
1. Its high level abstractions are computationally expensive. Sometimes this idea is supported by saying that garbage collection is very slow, sometimes by saying that the inability to directly manage memory means that it is done inefficiently, perhaps even inescapably so.
2. Compiling a program to an intermediary language that is not assembly but must be instead executed by something else (in this case, the JVM) must be slow.
Until then there are the IBM and Azul extensions, off heap memory, or optimizing in native code that 1% after using the profiler, where it really matters.
1) Controlling memory layout is not as big a deal as people think. The JVM is highly optimized (really it's probably the most optimized system ever devised) for allocating and deallocating objects on the heap.
2) It is in fact possible to control memory layout today because Java has access to offheap memory where you can have all the control you want.
This has actually been the case for nearly half a decade but for some reason a lot of people are convinced that "big arrays" can knock over the JVM.
In any case, bytecode as executable format, goes back to the early days when CPU were microprogrammed.
It was also a common approach on mainframes, with OS/400 being the best example.
High startup costs you say? Then don't use OpenJDK.
Get an AOT compiler to native code like Excelsior Jet or switch to a JVM that supports both AOT compilation to native code and JIT code caching like IBM J9 or Azul.
class scanning ? Again stop using OpenJDK and switch to a JVM that supports class sharing across VM instances like IBM J9.
For those that don't want ever to use anything other than OpenJDK, some of those features might eventually come there, like the newly introduced support for AOT compilation of the base module for Linux x64. With everything else planned for Java 10.
Bloated libraries? Well, there are bloated libraries in any programming language.
And by any change you are thinking of JEE, I doubt you had the pleasure to use C or C++ alongside DCOM, CORBA and SUN RPC, at enterprise level to fully understand the relief it was to change to JEE.
Also another example is those that perceive the JVM as slow due to using it with Clojure, when the slowness in this case is caused by the Clojure implementation itself.
I use Java since the very early days, and am well aware of them, as are my fellow Java developers, when I work in Java projects.
Even in more enlightened scenarios a REPL on jruby is just eye-wateringly painful unless you've all the "secret speedups" enabled.
In many more modern development cultures such secrets are generally looked upon as "Yak Shaving".
But on perceptions: naive perceptions don't justify a false statement. So why draw focus to them, why excuse them? Facts trump perceptions.
Also as mentioned elsewhere in the thread, trading systems don't suffer from frequent cold restarts, so hotspot work amortizes extremely well. So Java is much more optimal there than e.g. a command line tool.