Could Java ever match C++ with regards to programming ultra high frequency systems? Has the JVM improved enough to allow this? From a theoretical or practical point is it possible?
Is C++ used in most UHF systems simply because out of habit?
If you agree/disagree, what parts to Java/C++ is the basis for your viewpoint?
The inherent problem is the garbage collector. It's non-deterministic- something that UHF can never cope with. Working around this issue is basically equivalent to re-inventing native allocators. Moreover, the language carries a lot of intrinsic overhead that cannot be reduced, where C++'s constructs are directly more efficient- for example, a Java member variable has to be another reference, even if in reality it could be allocated as part of the block, which is how it's done in C++. This enforces extra indirection/cache overhead/etc. This means that a Java UHF program would be inherently significantly harder to write, for poorer results, than a C++ equivalent.
Fundamentally, high performance determinism is in the design of C++. It's not in the design of Java.
Edit: What I meant by "part of the block". In C++, a class or struct is allocated as one, single, big chunk- effectively, it's an array. This means that indexing into that array almost arbitrarily is pretty much free- that is, accessing a member variable in C++ is equivalent to an array index, for any nesting. In Java, however, every member variable of class type must be pointed to. This means that classes in Java necessarily form linked lists, which are massively slower to access. Every member variable you access in Java is a pointer de-reference, which is terribly slow in comparison. Now, in C++, if you need it, you can make pointers members and access through them, but in Java there's no equivalent option to make members into an array. This means that Java enforces the slower, linked-list access semantics. The same principle applies for many other similar cases.
And a concurrent GC is only going to help with a non-maximally-concurrent program. If you have a program that's using 100% CPU, there's no way to GC it without reducing the amount available for the program.
Yes it can if you design your data structures, objects and architecture properly (which is true under any platform). The Disruptor has more than proven this recently.
That said, C and C++ still offer natively lower level constructs than Java (which probably needs something like tuples to help push it over the edge)
Your Mileage May Vary (YMMV) with all of this.
For the speed sensitive part in High Frequency Trading, Java is just not good enough.
Java doesn't allow one enough control over object layout. In particular, it lacks a compact memory layout that the array and vector provide. An ArrayList of object references is not the same.
Java also has a non-zero object overhead, resulting in objects being larger.
Both results in cache misses, which worsens reaction time.
And in HFT, Winner takes all - There is no second place.
Lots of comments on the other answers incorrectly concentrate on the Garbage Collector. GC doesn't matter at all. During the speed sensitive part, GC won't be triggered. And there will be enough time between two speed sensitive events to do as much house keeping as required- no HFT system should be anywhere near 100% load.
Part of any as-fast-as-possible design, is postponing anything not crucial for sending out the order until after sending it. In fact, GC could actually help in that aspect! In practice, it is usually easier to just allocate the memory required on startup, and reuse it.
Of course, there are also parts that are not speed sensitive: GUI, post-processing, risk calculations, monitoring, and so on. Those parts can be done in almost any language, including Java.
