Real-time for what?
What counts as 'business real-time' depends upon the context. A real-time business process relies on timely data processing in order to function effectively. However, while a hotel booking system needs to know which hotel rooms are available, it doesn't need sub-millisecond data processing - but many trading applications definitely do.
Furthermore, the definition of business real-time isn't static in electronic trading, where the pressure to meet lower and lower business-driven latency targets has been intense. This also extends beyond just the speed of order execution systems, to include other systems, such as risk and portfolio management.
This latency race is apparent across every asset class. Remaining competitive and avoiding the risk of being gamed depend upon keeping up to speed. However, this goes beyond simply being fast in a one-off sense: the key is to be consistently fast.
In fact, depending upon the nature of trading activity, this ranges from being important, to mission critical. When buying individual instruments, latency is undesirable, but with more complex multi-legged strategies everything depends upon getting all legs
completed in the smallest possible time window: a glitch that leaves a leg lifted for several milliseconds is unacceptable. Therefore, speed consistency has become a major priority in trading.
An undeserved reputation
A common perception is that Java is slower than other languages. In many situations that isn't true of its execution speed and is definitely untrue of its implementation speed. Especially in a trading environment, where algorithms are continually being updated, this gives it a definite edge over languages such as C++. An accomplished C++ developer might produce code for an algorithm that ran faster than its Java equivalent, but its development time would be longer. When looking to exploit a transient opportunity/inefficiency, Java's implementation speed therefore gives it an advantage.
However, while Java can be very fast on average, it has historically suffered from severe inconsistency and execution pauses caused by its garbage collection process. Fortunately, this is directly addressed by Azul's Zing JVM. This means the noise levels for a Java-based system using Zing are now as low as those for a C++ system running on the same operating system.
While Zing takes the primary limitations of Java out of the development equation, further improvement is still possible. A good example of this that Azul has been pushing for inclusion in Java 9, is enhanced memory layout capabilities that would match the ability to manipulate arrays of structures in C based languages. If implemented, they would put Java on a par with C based languages' speed of access to similar data structures.
At present, developers use tortuous workarounds to try and achieve this in Java 8. The ideal is therefore to have a set of libraries that will allow developers to do this natively with idiomatic Java objects, while also allowing the JVM to optimise their structures to a performance level that matches C/C++.