[jandrewrogers]

You can write many of the bad examples in the article in any language. It is just far more common to see them in Java code than some other languages.

Java is only fast-ish even on its best day. The more typical performance is much worse because the culture around the language usually doesn't consider performance or efficiency to be a priority. Historically it was even a bit hostile to it.

[this_user]

Performance is really not Java's issue. Even bad Java code is still substantially faster than the bulk of modern software that is based on technologies like Python or JavaScript/Node.js.

[KronisLV]

This might also be why I heard colleagues saying “Nono, listen, these ‘N+1 problems’ and our nested service calls aren’t an issue because it works well enough” until it eventually didn’t. I’d rather not have bad code in any language.

Modern Java runtimes are pretty good, though.

[array_key_first]

No - this is not entirely true. Many of Java's fundamental design decisions lead to unexpected slowness that just does not happen in other languages.

For example, appending to a string in a loop. That only happens because of how Java handles strings. In C++, that's very fast. As fast as it can get, really. Since it all goes into the same buffer that gets mutated and expands at a good growth rate. Basically, equivalent to StringBuilder, but that's just all strings.

Or, boxing. C++ doesn't have to box generics to store them in a container.

[gf000]

> For example, appending to a string in a loop. That only happens because of how Java handles strings. In C++, that's very fast. As fast as it can get, really. Since it all goes into the same buffer that gets mutated and expands at a good growth rate

Well everything comes at a price. Just imagine how many billions of very hard to debug bugs did Java save the world from by going immutable on Strings, at the expense of some slow down when used without a though, and pretty much every java book starts with how to avoid it since decades?

[array_key_first]

Of course, I agree. My point is that it is a Java thing, not a computer thing. It was deliberated designed this way. Java has unique performance characteristics that don't apply to most other languages.

The same thing is true for C++. Value semantics have a cost. In C++, passing a string to a function is very expensive because it calls a copy constructor, so you have to remember to use a reference to avoid that. In Java, that's basically free because of reference semantics.

I also want to say that, while Java has immutable strings, that is a bit undone by the reference semantics of the language. C++ has mutable strings but value semantics, which means that passing a string to a function is safe. It won't be mutated, even though strings are mutable like most C++ containers. In Java, passing containers around is generally not safe, and you can't assume they won't be mutated.

[steve1977]

Which, to be fair, in many cases is ok. If you just need to churn out LOB apps for worker drones as cheap as possible, performance is probably not the most important factor.