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
Gil Tene (Twitter: @giltene) is CTO and co-founder of Azul Systems. He has been involved with virtual machine technologies for the past 20 years and has been building Java technology-based products since 1995. Gil pioneered Azul’s Continuously Concurrent Compacting Collector (C4), Java Virtualization, Elastic Memory, and various managed runtime and systems stack technologies that combine to deliver the industry’s most scalable and robust Java platforms. In 2006 he was named one of the Top 50 Agenda Setters in the technology industry by Silicon.com. Prior to co-founding Azul, Gil held key technology positions at Nortel Networks, Shasta Networks and at Check Point Software Technologies, where he delivered several industry-leading traffic management solutions including the industry’s first Firewall-1 based security appliance. He architected operating systems for Stratus Computer, clustering solutions at Qualix/Legato, and served as an officer in the Israeli Navy Computer R and D unit. Gil holds a BSEE from The Technion Israel Institute of Technology, and has been awarded 28 patents in computer-related technologies.
Here’s part two of our interview with Azul Systems CTO Gil Tene. Part one is available here.
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 process.
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 remain.
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 problems?
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 future.
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 guarantee.
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 Monday.
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 one.
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 hit.
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.