BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Azul Systems Discuss Java's Present and Future

Azul Systems Discuss Java's Present and Future

This item in japanese

Lire ce contenu en français

Bookmarks

Earlier this year, Simon Ritter, deputy CTO of Azul Systems, published a blog post covering new features in Java 12. With Java 13 now entering feature freeze, InfoQ caught up with him to talk about Java 12, 13 and everything that's been happening for Azul lately.

InfoQ: Let's start by talking about Azul's products. You ship two separate JDKs - Zulu, which is your OpenJDK distribution, and Zing, a high-performance proprietary JVM. How do those two markets differ for you as a company?

Simon Ritter: Zing is our commercial JVM, which is designed to optimize the performance of Java applications that need low latency and high throughput. The market for this is users who have demanding workloads that can't be handled by the non-deterministic nature of garbage collection.

Applications such as trading systems or web page advertising injection can't tolerate GC pause times that are proportional to heap size and need a different approach. Zing is a truly pauseless collector.

Zulu is our build of OpenJDK and is targeted at people who want an alternative to the Oracle JDK. Oracle changed the license for their distribution as of JDK 11, which means many people who relied on the free updates are now faced with paying Oracle or using a different distribution. Our Zulu Enterprise Edition provides full support with an SLA on when updates will be available at a very reasonable cost. This appeals to users for whom a free, unsupported version is not suitable for their needs.


InfoQ: Just to be completely clear, are the Zulu binaries that you produce GPL-licensed and freely redistributable? Can they be downloaded from the Azul website without needing to buy a support license?

Ritter: Absolutely. We have two versions of Zulu.  Zulu Community Edition is free to download from our website and use wherever you want. Zulu Enterprise Edition is the commercially supported version that has SLAs for update availability and a support channel for issue resolution.


InfoQ: You also have a product for embedded systems - how does that fit into the overall picture for you?

Ritter: Zulu Embedded is the third part of our product line that is targeted at either truly embedded systems such as smart meters, in-car infotainment, etc. or for those users who want to bundle a JDK with their application code to simplify installation.

InfoQ: Can you talk to the roadmap for Zing (Azul's proprietary JVM)? For many years, the key differentiator was the C4 garbage collector. Is that now under threat from new collectors in OpenJDK, such as ZGC and Shenandoah? How are you responding to the changing JVM market?

Ritter: Essentially, we're always looking for new ways to eliminate performance issues associated with the JVM. Being a managed runtime environment is excellent for simplifying development and deployment, but has drawbacks like GC pauses and application warmup time as the JIT compilers do their work.

We started with solving the problem of GC by developing C4 (the Continuously Concurrent Compacting Collector). That has had some changes over the years, but the fundamental approach (using a loaded value barrier, or LVB) remains the same.

Shenandoah takes a different approach to C4 and currently only uses a single generation heap. ZGC is a lot more like Zing in its approach, but is not completely pauseless. Both of these collectors are still in the experimental stage, so I don't expect many customers, especially those looking for demanding SLAs, will deploy these into production in the near future. We watch what other people are doing with interest.

InfoQ: What about other JVM subsystems?

Ritter: More recently, we've turned our attention to other parts of the JVM. We have replaced the C2 JIT with our Falcon JIT based on the LLVM compiler. This is delivering some great performance results, especially in areas such as exploiting vector processing in better ways. To reduce warmup time, we developed ReadyNow! that takes a snapshot of a running application and uses this to load and initialize classes and compile methods before the main entry point is reached.

The most recent development is Compile Stashing that saves compiled code from an application run and uses it effectively as a cache to reduce the amount of compiling that is required when ReadyNow! is used. The JVM spec is very detailed on what you can and can't do at startup, which makes being able to pass the TCK (which we do) challenging when we come up with new ideas.

InfoQ: Are any of these technologies open-source? Is there any possibility that they would be opened in future?

Ritter: As this is a commercial product, we do not make the code available under an open source license.  Whether this will change in the future, we'll just have to wait and see!


InfoQ: What is Azul's experience of the uptake of non-LTS releases of Java? Are people actually using them in their production systems?

Ritter: I talk at a lot of conferences and always poll the audience on who is using which JDK versions in production. Most people are still on JDK 8 with an increasing number making a move to 11. The percentage who have move to JDK 11 is still in the range of 10-15%, from a show of hands. Very few people are using the non-LTS versions based on these informal surveys.

InfoQ: Let's talk about Java 12 - and in particular the new Switch Expressions feature. How useful do you think it is? From what you've seen, are developers adopting it?

Ritter: I think this a useful feature that will take one of the rough edges off Java.  Having much of its syntax based on C, Java has had to contend with places like switch where things could have been done differently to make life easier.

Having to separate individual case statements and the problem of dropping through without a break have always been somewhat annoying. Making switch an expression, as well as a statement, is excellent because now an assignment only needs to be made once, eliminating a potential source of errors.

I've not heard anyone raving about this feature in the way they did about lambdas and streams. As it's only available in JDK 12 (and only then as a Preview), I suspect its use will be limited until we get to the next LTS release.

InfoQ: What about the Preview Features mechanism as a whole? Do you think it's proving to be useful? Are there any concerns that you have about it?

Ritter: I think this is working well.  Switch expressions were the first feature to be added as a preview, and we have already seen the benefit of this. The JDK 12 version use `break` with a value to maintain the old style look-and-feel.

Although you can't use a numeric value as a label, this could be confusing if you have code that also breaks out of a loop to a label in conjunction with a switch expression. In JDK 13, the decision has been taken to change this to use yield instead (JEP 354) to add clarity. If this had not been a preview feature, it's not clear if we could have made the change in this way as the syntax would have been included in the Java SE language specification.

InfoQ: Can you compare Preview Language Features to the Incubator APIs (such as HTTP/2 support, which initially arrived as an Incubator)? How are they different from each other, in your opinion?

Ritter: They are really the same except one (incubator modules) applies to the API, and the other (preview features) refers to the language syntax. Both allow new features to be added without fixing them in the specification. They can then either be modified or even removed entirely if feedback warrants it without needing to change the specification. To evolve a platform like Java in a considered way, these approaches make a lot of sense.

Personally, I wish this had been introduced a long time ago so we could have avoided some issues.


InfoQ: Java 13 is about to feature freeze. What is your take on the contents of the release - which are unlikely to change meaningfully between now and Java 13's GA in September?

Ritter: JDK 13 is going to be another release that does not include a large number of features; there are only five JEPs scheduled for inclusion. Developers are unlikely to rush to move to this release. The idea of the new release cadence is a steady flow of new features giving us a similar (or even faster) pace of change than we were used to with the old release schedule.

There are several big projects in progress at the moment (Valhalla, Loom and Panama are good examples). When we see these delivered, some releases will have a lot of new features included. The important thing is that Java continues to evolve and is not becoming stagnant.

InfoQ: Speaking specifically about Text Blocks (previously known as "multi-line strings"), is this an example of Wadler's Law in action?

Ritter: Yes, it's funny how some of the smallest features seem to require the most discussion.  Java has had several bike shedding issues in the past.

There are good cases for where multi-line strings will simplify some syntax, but having programmed in Java since JDK 1.0 I can count the times I would have really needed this on one hand.


InfoQ: There has been some lively discussion on the OpenJDK mailing lists recently, which Azul staff (notably Gil Tene) have participated in, in the area of the Docker OpenJDK images and how the Debian project takes source and builds binaries for their releases. Can you give an outline of the issue, and describe whether you feel it has been resolved satisfactorily?

Ritter: The issue is what Gil describes as "mystery meat JDKs" and has to do with the misuse of version strings for JDK binaries. Some of the binaries being made available had update numbers that were for the next update before it had been released.

The issue is then one of trust about whether something that says it is JDK 8u212 actually contains the changes from that update. There are many sources of JDK binaries and users clearly need confidence that they are getting what they think they are getting. We will need to see how this works in future updates before we can be sure it has been resolved.

InfoQ: With OpenJDK 8 no longer being managed by Oracle, one of the initiatives that is now possible is the backporting of features or patches that Oracle were reluctant to undertake. One of the most visible examples of this is the backport of Java Flight Recorder (JFR) to OpenJDK 8, which Azul has been deeply involved with. Can you explain why the backport is important, how Azul got involved in it, and give us an update on where we are with the patch?

Ritter: Flight Recorder is a set of features that need to be built into the JVM to allow detailed metrics to be collected about how the JVM and an application are performing.  This data is used by the Mission Control application that Oracle also open-sourced as part of the convergence between the Oracle JDK and OpenJDK.

The Oracle JDK has Flight Recorder integrated into JDK 8. At that point, it was still a commercial feature that required a paid license to use in production. Now that free public updates to Oracle JDK 8 have ended (at least for commercial users), people are migrating to OpenJDK 8 builds that do not have Flight Recorder.

As you say, Azul has been working on Flight Recorder backporting to OpenJDK 8 and now include this in our Zulu 8 binaries. We are working with other OpenJDK contributors to make this part of the OpenJDK source.

InfoQ: Are there any other major OpenJDK initiatives that Azul is involved with, or that you'd like to see started?

Ritter: Azul is heavily involved in all aspects of the Java ecosystem. We have been part of the JCP Executive Committee since 2011 and on the Java SE Expert Group since Java SE 9.  One of our engineers, Andrew Brygin, is project lead for OpenJDK 6 and we continue to contribute to the OpenJDK project with things like JEP 285 (Spin-Wait Hints). We will continue to support the OpenJDK as well as the broader Java community through activities like JUG visits and sponsoring AdoptOpenJDK.

 

Rate this Article

Adoption
Style

BT