Tom Groenfeldt
, ContributorI write about finance and technology.Opinions expressed by Forbes Contributors are their own.

Here’s something new to worry about — Java, the programming language widely used in financial services — requires warmup time to operate well, a problem that is getting some air time now that Azul Systems has developed a solution which it is promoting.

Although Azul touts the new software, called “ReadyNow!” as a way to avoid problems like Knight Capital’s faulty trading that lost the firm $460 million, it backs away from saying Knight had a Java warmup problem. Indeed, as klockwork explains in a post, citing SEC research, the Knight disaster arose from changes in code that hadn’t been properly tested.

Azul’s CEO, Scott Sellers, backs off linking his software to the Knight issue when he explains that “The types of behaviors that would characterize a Knight Capital is what we are trying to prevent with our technology.”

Almost anyone in a trading, market making and pricing who is using Java, has problems with the warmup Java requires.

Java is the world’s most popular programming language with more than 10 million developers using it, said Sellers, and it is used by 80-85 percent of Global 2000 enterprises. It was designed as a general purpose language, which does create some challenges in the more sophisticated and performance demanding environments, like financial trading, he added.

“While it is generically good, it is not great at some specific areas, especially in financial services.”

Java was designed as a general purpose language, he added.

“Sun created ‘Write Once Run Anywhere.’ Java is different from other languages because a developer doesn't have to target certain machine configuration when he writes Java code.”

The app itself gets compiled into the underlying instruction set for Windows, Unix, Linux on a server, laptop or mobile when it starts running.

“That is very different from other languages where you target a certain platform as you develop it. The fact that the compilation is just in time is once of the niceties of the runtime environment, but the downside is that it does create some challenges in certain environments.”

Java performs better as it moves along. When it starts, its first goal is to get up and running reasonably quickly, Sellers said, but compilation is a multi-step process.

“There is a tradeoff between how quickly an app starts and how well it can be fully optimized, fully complied and ready to execute trades at full performance level.”

To get around this problem, companies with critical operations, like financial services firms, often run warm-up Java apps with data so the compilation process is optimized before trading begins.

“I need that trading system to be up and running at market open,” Sellers said. Some firms prepare their Java applications by sending fake trades through the application and then stopping them before they execute.

“They have found the best way to warm up the system is to send what look like real trades through it, but because they are synthetic, they are only so good at mimicking a real trade. Every day is different and market conditions are always changing.”

An app that hasn’t fully warmed up can act inconsistently, not exactly a quality one wants in a high-frequency trading or market-making environment.

“You can get hiccups while compilation slows or stops for a fraction of a second. How long the hiccups last depends on the app. In a run-of-the-mill trading platform without a lot of logic associated with it, this may not be bad. Eventually the problems work themselves out.”

Eventually is a long time in high frequency trading with very complex decisions that place thousands of trades and cancel most of them.