Java is the most successful development platform of all time, and is currently used by more than 17 percent of developers, according to last month's Tiobe Programming Community Index. However there is concern within the developer community that the Java platform is ageing, with some suggesting that Java could become the next Cobol.
According to Gil Tene, CTO and co-founder of Azul Systems, however, this is not the case. While he admits that the Java Community Process (JCP) has been stagnant in standardisation over the last five years, activity has picked up in recent months, and work is being done to standardise not just the current version of Java, but also future iterations of the platform.
The worries about displacement of this platform by something else will always be around, and if ever something much better comes along it should displace this. However, I haven't yet seen that something else yet, says Tene.
The power of standardisation
Azul Systems has built scalable Java Virtual Machines (JVMs) for the last nine years. A JVM is a layer that sits between the operating system and the application, to translate code and execute it on a specific operating system and a specific hardware. Azul is also an elected member of the JCP Executive Committee, which Tene describes as the “steward” of the Java platform.
Tene believes that one of the things that has made Java so successful are:
- the fact that it is strongly standardised
- the standard is also strongly policed
“Java has not fractured. There's a TCK (technology compatibility kit) that has verified that it really does work the same way, and when you ship a JVM, you know that Java programs will just run on it,” says Tene. “That was not a given 15 or 16 years ago. That's not how other platforms behave, and I think it's probably one of the biggest innovations the Java platform brought through.”
He explains that a lot of the efforts around standardisation are to ensure that additional languages are able to use the JVM platform. For example, Scala, which Tene regards as an up-and-coming force, runs on JVM and interacts with Java applications.
“Java the language may be ageing, but Java the platform is the thing that runs all modern languages. So when people talk about a language that will replace Java, that language will probably run on the same JVM,” he says.
Another reason for Java's success, according to Tene, is that Java developers only need to write code for the application they are developing, whereas in most other environments they also have to write software for all of the infrastructure supporting that application, including
- application server
- messaging system
“That power is immense,” says Tene. “Cobol never had that. C and C++ don't have it. Tuxedo back in the 90s had it to some degree, but Java completely displaced it because it's so much easier to use.”
Oracle has done the right thing... so far
When Oracle announced it was buying Java creator Sun Microsystems in 2009, many developers were worried that Oracle – which has a reputation for lock-in – would attempt to block access to Java. So far, however, Tene has seen no indication that Oracle is doing the wrong thing.
“Probably the biggest worry that people have is that Oracle will shut everybody out, and if you want to use Java, you will have to run on Oracle software and Oracle hardware, and pay Oracle money and nobody else,” he says.
“I don't think that's a realistic worry because Java is so prevalent in the industry that it would be really hard to actually do that and, more importantly, Oracle has done all the right things to show that they're not about to do that.”
Tene explains that Oracle has helped to make the Java Community Process much more active than it was before. It has also invited companies like Azul to join the JCP actively, to help guide the rules of licensing and engagement, and is looking to share power with stakeholders such as IBM.
The JCP's role is to steer the future of Java by selecting and approving standards. While the JCP cannot veto any of Oracle's decisions, the community as a whole does have power over Java, and if the majority of the community acts then it will have an impact, according to Tene.
“Oracle could potentially have said, screw the community – this is ours and we will do what we want with it. They have very clearly chosen not to do that,” he adds.
Tene still shares the worries of the rest of the industry that, just because Oracle seems to be doing the right thing now, does not mean it won't try to monetise Java in the future. However, he points out that Sun was a very altruistic steward of the Java platform, and arguably did not monetise it well enough.
“A lot of other people made a lot of money off the Java platform instead of Sun,” he says. “I think we need to find a balance somewhere in the middle. We have access now, and we'd like to make sure that access continues.”
Although Azul Systems works together with Oracle and IBM on the Java specification, it is also in direct competition with both companies. Tene claims that, unlike the JVMs offered by Oracle and IBM, which can only use a small percentage of a server before scale and performance taper off, Azul can run a single JVM at the scale of a modern-day server.
He explains that a regular JVM from Oracle will stop behaving when it reaches around five gigabytes of memory, which is just one to two percent of the size of a commodity Dell server with 16 CPU cores. The common practice is therefore to put lots of JVMs on a server, which means breaking the programme running on it into pieces.
“When you needed two or three JVMs to fill up a commodity server, that was a little bit of friction. At the point where you need 20 or 50 or 100, or in a couple of years 1,000 just to use a $10,000 computer, at some point the absurdity of that becomes obvious,” says Tene.
He explains that, because Azul's heritage is building high-end JVMs designed to run with tens of CPU cores and tens of gigabytes of memory, those same JVMs are now able to scale to the size of current server hardware. “What was high-end 10 years ago is now commodity,” he says.
Azul's JVMs are elastic, and can expand and contract according to demand. Tene claims that Azul JVMs will scale smoothly from a gigabyte to half a terabyte and back again while continuing to run smoothly, while users of IBM and Oracle JVMs are limited to a box that is much smaller and rigid.
“When you have a computer and each piece can only be one percent, it's hard to share the computer well,” says Tene. “If each piece can dynamically go from using half a percent to 50 percent and back elastically, then you have shared headroom that everything can tap into it when it needs it.”
This is particulary important in a cloud environment, where there are are large numbers of customers sharing the same infrastructure. One of Azul's key customers in the US is SaaS platform SuccessFactors (recently purchased by SAP), whose entire platform runs on Azul JVMs.
The latency issue
The main reason that Oracle and IBM keep the individual instances of Java small is because there is a response time behaviour problem that grows with scale, according to Tene.
One of the things that makes the Java platform extremely productive for developers is an action called Garbage Collection, where the machine finds memory that is not being used and recycles it. Historically, this process involved stopping the application every once in a while, doing the clean-up, and then resuming the application.
For industries where low-latency is paramount such as high-frequency trading, a “hiccup” of more than a few milliseconds could be devastating, says Tene. There are various techniques for making the hiccup as short as possible, but stoppage is inherently linear in size to the amount of work and memory.
It is this link between the hiccup and the size of the JVM that has prompted IBM and Oracle to keep their instances small. However Azul claims to have found a way to eliminate the hiccup associated with Garbage Collection entirely.
“Our garbage collector runs concurrently without stopping the application at all, so it's able to do its job and recoop that memory at any size, without having to stop the application from running,” says Tene.
“The low latency guys like us for the fact that our response time is consistent and very short at all scales, and the high-end enterprise people are about being able to do scalable problems without sacrificing response time. Those are two sides of the same coin from a technology point of view.”
Java lives on
In ensuring that all kinds of applications run well on JVM, Tene is confident that developers will continue using the Java platform. However, he admits that they won't necessarily be writing in the Java language.
“Java is 15 or 16 years old now, and there have been many innovations in that time,” says Tene. “Languages like Scala, Clojure, Ruby and Python are newer, and whether it's content from those languages that make it into Java, or simply running programmes alongside Java on the same Java platform, one of those things is going to happen.”
He points out that neither Ruby nor Python were on the JVM platform to begin with, but when people developed JVM-based implementations of those languages, they out-performed the originals.
“Our job is to make sure that these things run well on the JVM, so those developers don't go somewhere else,” he says.