Talking Java with Gil Tene, Azul Systems
Part Two of our chat with Azul Systems CTO Gil Tene, this time discussing all things JDK and Project Jigsaw
Here’s part two of our interview with Azul Systems CTO Gil
Tene. Part one is available
JAX: You’re obviously a part of the Java Community
Process, particularly the Executive Committee to which you voted
into back in November 2011. What were the main drivers for doing
this and what do you hope to achieve from it?
Gil Tene: So Azul lives and breathes Java. We build scalable
JVMs. We have been part of the JCP for nine years, but we’ve mostly
been receiving in parts. Everyone else did a lot of work and we got
the benefits from it.
I think that our decision to be more active was driven by a few
things. One of them was that two different things creating
stalemates in the JCP. The first the contention on licensing and
whether Apache and Harmony were allowed to use TCKs or not.
Regardless of what side of that discussion you fall on, the
discussion itself created a freeze in activity in the JCP because
that single thing drove votes on platforms and JSRs, based on ‘I
will not vote yes, until that’s taken care of’. Sadly, this stalled
The other thing was that with the Oracle acquisition of Sun, across
the entire industry everybody became very suspicious of motives.
You may or may not agree with how Sun ran things before, but I
think that across the board, it was a pretty neutral steward of
Java. People didn’t really worry about competing with Sun and
therefore be worried about access to Java.
When Oracle bought Sun, suddenly when you were making software, you
were probably competing with Oracle. Now you’re dependent on the
technology your competitor owns and everybody had key questions of
whether or not, the openness and access that was there before will
We had the same concerns, we have the same concerns but all the
signals we have seem to indicate that Oracle is trying to do the
right thing and is not closing access. They’re not trying to change
what the ecosystem looks like. But trying and looking aren’t the
same as doing. What we decided to do about that was to join the
Executive Committee of the JCP and actively participate in the
process. If we don’t want the JCP to be a one company organisation
and a rubber stamp, that means that people other than that one
company have to actively participate and actually have to do
reasonable things in there.
Our role is to hope that what is said is what will be done and to
closely watch that at the same time. To signal talk about things
early before they grow into problems.
JAX: What specific examples would you cite as possible
GT: OpenJDK is something that I think is great. A good move by Sun,
Oracle seems to be fully behind it. Java is being developed in the
open and taken into closed source from there, rather than the other
way round like before. Access is there, the code is freely
available. You can leverage it, you can build things downstream
from it if you wanted to. All the good will I believe really does
exist there. It’s our intention to make our products based on that
codebase, as opposed to the closed source license codebase, in the
But when you actually look into OpenJDK, one thing that is missing
is visibility into the future. I think that everything is right in
terms of the ability to use it, test with it, leverage with it. But
if you decide as a company or individual to invest your time and
efforts into contributing into OpenJDK, basing your stuff on it,
you have a guarantee for the next year, you can use it. But you
don’t have the ability to predict whether three years or four years
from now, you absolute would. It’s not that that won’t be taken
away, there’s no intention of that – it’s just that there’s no
That’s specifically true for OpenJDK, and true in other places, but
usually it is handled by a commercial agreement. It’s a very
uncomfortable situation to be in because if you’re going to invest
your efforts, you want to know that you have several years left to
reap the benefits. You also have the visibility that if it’s going
to go away then, you will know about years in advance, not next
As part of the rule changes for the JCP, one of the things that
we’ve been advocating for is a minimal visibility into how long you
will retain access once you have a license.
JAX: Any others?
GT: There’s some less high-strategic things that are both
procedural. The JCP is moving into a lot more open process where
there are no secret discussions in JSRs. You know, with technical
discussions, any JCP member at least should be able to see not just
the result of the discussion, but the logic of flow behind it, and
be part of the conversation if they want to. Or at least be able to
critique it. That change has already happened and it is a welcome
But open doesn’t necessarily mean open source. I’m a big proponent
of open source but it shouldn’t be forced on anybody. I don’t think
you should force open source licensing as a rule, anymore than you
should force closed source licensing.The role of the JCP is to make
sure we have the ability to build implementations of a standard.
Compliant compatible implementations that don’t fragment the
platform. That to me is the goal of these things – whether these
implementations are open or closed, free or for charge, there
should be multiple of them and let them openly compete. And may the
best one compete.
JAX: Moving on to more recent news – Project Jigsaw isn’t
going to be in Java 8. What is your opinion on that and was it the
right call to defer?
GT: I was sorry to see that happen because I think it’s a very
useful thing and it would help unleash a lot of productivity in the
community. But I also think it’s probably the right thing to do,
given the schedule and the state of the project. I think it is more
important to start reliably delivering Java releases on time than
it is to have features in them. Java 7 took way too long and more
importantly, it eroded the public expectation of moving.
The right way to think about it is that there should be a Java
release, that is after Java 7, sometime in the second half of next
year. That should not be delayed. Features should be put in the
releases that can accomodate them. Jigsaw is not a Java 8, 9 or 10
feature – it’s a feature we want and it should get a release we can
Having said that, taking a JCP position here, one of the things
that needs to happen for Java 8 to hit its deadlines, is that the
Java 8 JSR needs to make progress in getting to a final draft. The
Java TCKs need to be available in a form we can examine and give
feedback on because if we expect a GA release of Java 8 in the
summer, we have to approve a JSR well ahead of that. I think you
see good progress in OpenJDK around this, but I would like to see
more active JSR activity, with discussion and some sort of a
feedback cycle rather than “We’ve done all this work in OpenJDK,
now we just need to approve.”
JAX: What are the plans for Azul Systems – if you can
divulge any information there?
GT: We recently completed the transition from a hardware-centric
business model to a software only one. That culminates with Zing
primarily being a native JVM for Linux x86 commodity servers. We
don’t plan to have a similar size shift any time soon! We think
that this opens tremendously large markets for our product that
were untouchable before. Our plan is to mostly continue delivering
and grow into those markets.
On a technical level, we’ve been delivering various levels of
pauseless GC activity for years, and now we have them in easier to
consume forms. We keep improving the metrics in low latency areas,
because in practical terms for enterprise applications with human
response times, Zing completely eliminates garbage collection as
something you should even think about. But if you’re in the low
latency/high frequency trading market, there’s still stuff to be
done. We’re probably much better than anything else but we can
still improve. I believe that we can reach a hypothetical worst
case of 20 microseconds garbage collection
latencies visible by an application. Zing is nowhere near that. It
is in the sub millisecond level, reliably. But we can go much
further, we might do that.
From a product perspective, it’s to deliver what we already have
and improve upon it. Right now Zing is a Java 6 JVM, we will
deliver a Java 7 version soon.