Why do people still say Java is slow?

Recently I found some very interest discussion on Java performance, actually title of this post is from a question on stack exchange:

http://programmers.stackexchange.com/questions/368/why-do-people-still-say-java-is-slow/5064#5064

As I see, there are mainly two reasons for this (also could be found in the link above):

One reason is that people trust what others say instead of what they see.

According what I was told when I first started programming, Java is "slower" than C++, and reason why Java could be used is because it's "convenient and easier". It's very commonly believed that Java brings Safety and convenience, at the cost of performance. Even when later C# is invented people believe it's faster than Java because it's "native".

But the truth people see without sensing it, is that, eclipse, the IDE that's built with Java, is absolutely the FASTEST IDE in class. I've used nearly all main stream IDEs, those from MS and GNU, Borland..., eclipse is the absolute king, of IDEs, largely because of it's fast.

Another reason is its long start up time.

Java is not suitable for developing a tiny app that stay in system tray, consumes a little memory, popup a dialog reminding you to take a break; or a notepad that you use to open a text file, read it and close it. It should be used on something BIG, like a web server that's always there, make optimized use of you computing resource, respond to millions of requests every hour. Or an IDE like eclipse that manage thousands of workspace files. You don't know you Java app is fast until it has run for at least several hours, I believe.




Also there's proof that java DO is slower, although a little bit, than other even high level programming languages:

Modern Java is not slow, as others have noted. But, there are a couple exceptions:

• Array access is still MUCH slower compared to C, due to bounds checks and so on. This improves with every version, and Java 7 should provide a massive boost here.
• Lack of arbitrary memory access can make some I/O and bit-level processing slow (compression/decompression for example). This is a safety feature of most high-level languages now.
• Java uses a LOT more memory than C, and if your application is memory bound or memory bandwidth bound (caching, etc) this makes it slower. The flip side is that allocation/deallocation is blazing fast. This is a feature of most high-level languages now, and due to use of GC rather than explicit memory allocation.
• Streams-based I/O is slow as shit due to the (IMO poor choice) to require synchronization on stream access. NIO fixed this but is a pain to use. Java 7 should fix this with a new stream-based but unsynchronized I/O library.
• Java doesn't provide the same low-level functionality C does, so you can't use dirty tricks to make some operations faster. This provides portability, but you can't use (for example) inline assembler or clever x86 tricks. This is a feature of most high-level languages now.
• String operations are slow. Java uses immutable, UTF-16 encoded strings. This means you need more memory, more memory access, and some operations are more complex than with ASCII. It's the right decision for portability but carries a performance cost.
• Startup times still suck. If I recall correctly, useless, bloated crap like CORBA still gets loaded or at least handled in some fashion.

In the end, Java was designed to provide security and portability at the expense of some performance, and for some really demanding operations it shows. Most of its reputation for slowness is no longer deserved. Still, Sun always chooses the "better" way rather than the "faster" way whenever it can.