The grandparent made specific claims about scenarios where Java is supposedly faster:

> Yes, Java can be faster in certain contexts: the kind of contexts Java is usually employed in addressing these days. Stuff like enterprise backend systems and big data processing, where startup time or precise memory control are not important.

The only thing that might be relevant in your list is the vectorization API.

The rest of your list is just a bunch of band-aids for the worst problems that Java specifically has, that other languages lack. That is at best playing catch-up with everything else, since in C there is no GC overhead, almost no startup time, no object overhead, no GC-induced memory hogging, no GC pauses. Yes, I agree that things did happen. But nothing in there makes Java any more desirable for relevant workloads, it just makes it less undesirable.

▲

gf000 4 days ago | parent [-]

And I'm gonna walk everywhere on foot from now on, because I don't have to drink petrol.

Are you even aware of the word "tradeoff"?

▲

holowoodman 4 days ago | parent [-]

Ah, now the excuse for being slow is "tradeoff".

▲

gf000 3 days ago | parent [-]

"Slow" means nothing without context. The proper context is the performance, productivity, future maintainability, debuggability and a bunch of other factors in relation to the given business requirements and goals.

	▲	holowoodman 3 days ago \| parent [-]
		The current context is compiler optimizations, as per the original article. That means we are talking about performance as a compiler produces it (or doesn't).