> Why wouldn't they take it?

Because the pool of Java devs is only marginally wider than the pool of C++ devs? 5.4M C++ devs vs 7.1M Java devs is not a massive difference in pools:

https://www.daxx.com/blog/development-trends/number-software...

And while I don't have numbers for it, my experience has been that the vast majority of Java devs have very little experience with the kind of specialized use of the JVM that low latency programming requires. On the contrary, I've found it difficult to hire for high-performance Java codebases, because the way they are written is completely different from how "normal" Java is written, so you need to retrain devs used to writing "normal" Java.

I believe I misread your first sentence, I thought you said every prop shop IS using Java. I have seen this specific claim so many times that I must have filled in the word.

The reason not to use java for low latency latency is that good low latency Java is pretty much only Java in a syntactic and to some degree object sense. Avoiding allocation permeates everything, and is just not worthy the battle.

You basically try to write C++ in Java, except without the language features of C++ to help with memory management and layout, and wit the added burden of having to worry about pools and primitive boxing and the runtime at every corner.

You would also be surprised though at how little hardware has replaced C++ on Linux with good user space networking. Not that many trades are pure latency arb, so getting that last microsecond or two just isn’t worth the effort.

It’s much more common to see hardware in fixed-function locations than it is to see hardware running the meat of a strategy.

The C I saw written in Java was filled with object pooling bugs and horribly unsafe code dealing with object layouts in off-heap memory.

The amount of bugs springing from just these far outnumbered memory bugs in the C++ and C codebases.