> While there have been improvements, Java performance work seems to have stopped after 2011 or so.

No idea how you got that impression. Here is an incomplete set of important changes:

- major developments on Graal and native code compilation for applications that prioritize startup time and memory use (I think Graal was started before 2011, but has changed a huge amount since then).

- the concurrent G1 garbage collector became the default, making most applications have much lower pause times (I believe it was released in Java 7 in 2011, but was not mature, only became a default in Java 9, and has regular improvements since then).

- the Shenendoah and ZGC concurrent garbage collectors were not started until well after 2011

- project lilliput, which reduces the header size of Java objects from 16 to 8 bytes is landing in Java 25, which comes out this fall

- specializing strings to use 1 byte/character for ascii strings, and 2 bytes for non-ascii strings

- virtual threads shipped in Java 22

- work on a vectorization API

- plenty of work on reducing the startup time of the JDK and modularizing it

One where I'm not sure about the timeline:

- https://docs.oracle.com/javase/8/docs/technotes/guides/vm/cl... class data sharing to lower overhead of running multiple JVMs on a single node

P.S. I'm not writing this to comment on the the parent's claim that Java is faster in some contexts.

▲

holowoodman 4 days ago | parent [-]

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).