It’s time to put a spotlight on ZGC and dim Nashorn’s star: Java influencers weigh in
Last week, our Java influencers discussed the importance of Java 11 and whether it can convince developers to drop Java 8. Now it’s time to continue the conversation we started in the second part about the door that closes and the one that opens. Can you guess what technologies we’re talking about?
One door closes, another opens
The JDK is an ever-changing environment; some tools are leaving, others are arriving, and the lucky ones live to tell the tale.
We talked about this “spring cleaning” in the second part of the interview series but now it’s time to talk about the door that closes and the one that opens. Can you guess what technologies we’re talking about?
Don’t miss the first three parts of this Java influencers interview series:
Meet the Influencers
Markus Eisele: It is hard to compare Nashorn with GraalVM. First of all, there are many projects under that acronym. It’s a new JIT compiler for HotSpot, and also a new polyglot virtual machine. I personally see it as an opportunity to rethink the compiler design for Java and other languages. Re-creating a better Java compiler in Java has a lot of advantages in general.
I’m sad to see Graal go with a GPL license, which makes it impossible to be used by Apache Foundation projects, for example.
Guillaume Laforge: Nashorn and GraalVM are two totally different things. The former is really an embedded language while the latter is a new Java VM kind.
For alternatives to Nashorn, as I mentioned before, there are already variable alternative languages that easy to add to a Java project, such as the Apache Groovy programming language.
GraalVM is definitely an interesting project though, as it promises an easy multi-language integration story. But I’m more interested in the capability of building native images, which gives the ability to have apps starting more quickly, taking less space on disk and in memory.
I’m sad however to see Graal go with a GPL license, which makes it impossible to be used by Apache Foundation projects, for example. I wish Oracle changed the license to something like an Apache license for more wide-spread possible usage.
Lukas Eder: I definitely think that Nashorn and similar engines do not belong in the JDK. I have no opinion on them being independent third party projects (regardless if by Oracle or some other vendor).
Let’s face it. JAXB was added to the JDK and removed again. Rhino was added to the JDK and removed again. JavaDB / Derby was added to the JDK and will be removed again. JavaFX was added to the JDK and will be removed again. Nashorn…
I think the JDK should not include any such “third party” tools. And people should not rely on those tools being part of the JDK.
Graal is an exciting horizon! I’m experimenting with it and they’re advancing by leaps and bounds. I’m particularly a fan of the language interop under the same platform and the native image builder.
If Nashorn is important enough it will be kept alive.
I think the GraalVM is currently the most important innovation in the Java space. Since the very beginning, Java has been using a bytecode. Even this basic principle is changed if needed. This kind of innovation and flexibility without sacrificing too much backwards compatibility is the reason why Java is still relevant after such a long time.
How do you feel about ZGC? Can it make latency a non-issue for Java applications?
Markus Eisele: An interesting approach. Azul has had large heap garbage collection for a very long time already. Red Hat has Shenandoah. With ZGC coming to the OpenJDK, it will deliver an alternative for scenarios that need this and can’t work within normal heap sizes.
What I feel though is that there are very few niche use-cases that are profiting from this. Especially with microservices architectures, where everything is about super quick startup times and small footprints. The low latency parts will, for sure, meet these requirements.
There are some first numbers out in the wild in a Fosdem presentation which look promising.
Guillaume Laforge: For short-lived apps, like small microservices that should spin up fast and last only for a few seconds, I think it’s a welcoming change.
Java has always had complaints because of its slow startup time, and the pauses some GC cycles were imposing, so this should definitely help there.
Of course, this shouldn’t be used for long-running apps, otherwise you’ll quickly run into memory issues.
There have been a lot of use-cases over the years that would lend themselves to this GC.
Josh Long: What’s not to love? There have been a lot of use-cases over the years that would lend themselves to this GC. Big data and online transactional systems come to mind. We’ve seen interesting developments, like off-heap memory for various data grid technologies and the remarkable work of Azul’s Java virtual machine in supporting large heaps, that could perhaps benefit from ZGC.
Lukas Eder: I’m not too much in that business, so I cannot comment.
Eberhard Wolff: Maybe. It is certainly a major shift and might eliminate a major problem with Java. However, garbage collection is tricky and must usually be tuned in production. So I would rather wait until we have more experience with how the ZGC actually works in production and where the shortcomings are.
Martin Thompson: Garbage collection is a major issue for many Java applications and yet a lot of Java developers do not realise this. In distributed systems, network partitions are much more likely to be caused by GC events than actual network failures. I have seen Azul Zing be successfully employed to eliminate garbage collection issues allowing designs to work with large memory spaces at significant allocation rates without issue.
ZGC has the potential to be a nice alternative to Zing but it will be limited with the Zing Linux kernel memory module in its performance. GC is a space seeing some nice progress. Java 10 eliminated one of the major issues with G1 by removing the bottleneck of full GCs being single threaded and now a parallel algorithm is used, hopefully thread checkpoints can improve the write barrier cost. We are also seeing more competition with Shenandoah from Red Hat and Epsilon No-Op Garbage Collector providing a baseline to compare GC implementations against.
Does it solve the latency issue for good? No, but it’s a good step forward.
Quentin Adam: ZGC is an impressive piece of software, I’m impressed. It will help JVM to scale on many humongous workloads and continue to rules the big data market. Does it solve the latency issue for good? No, but it’s a good step forward. But as there is no perfect tool for every need, from fixing a washing machine to building a wooden house, computer science can use several tools to fix the problems we face.
Sometimes a Garbage Collector is a problem, and as GC will always introduce latency, you need to use some non-managed language like Rust or C. As the Java platform already has a wide landscape of usage, the interest of ZGC is to be more performant on it, as the demands grow and the hardware progresses too.
Next week, we’ll discuss the features our Java influencers would like to see in JDK 12, as well as the role of serverless in Java’s future.
If you’d like to meet the top Java movers and shakers, join us in London in October.
17 features for JDK 11
Just to freshen up your memory, JDK 11 includes the following features:
Introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language. Nests allow classes that are logically part of the same code entity, but which are compiled to distinct class files, to access each other’s private members without the need for compilers to insert accessibility-broadening bridge methods.
Extend the Java class-file format to support a new constant-pool form,
CONSTANT_Dynamic. Loading a
CONSTANT_Dynamic will delegate creation to a bootstrap method, just as linking an invoke dynamic call site delegates linkage to a bootstrap method.
Improve the existing string and array intrinsics, and implement new intrinsics for the
java.lang.Math sin, cos and log functions, on AArch64 processors.
Develop a GC that handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down.
Remove the Java EE and CORBA modules from the Java SE Platform and the JDK. These modules were deprecated in Java SE 9 with the declared intent to remove them in a future release.
var to be used when declaring the formal parameters of implicitly typed lambda expressions.
Implement key agreement using Curve25519 and Curve448 as described in RFC 7748.
327: Unicode 10
328: Flight Recorder
Provide a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM.
Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a relatively new stream cipher that can replace the older, insecure RC4 stream cipher.
Enhance the java launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of “shebang” files and related techniques.
Provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI.
Implement version 1.3 of the Transport Layer Security (TLS) Protocol.
The Z Garbage Collector, also known as ZGC, is a scalable low-latency garbage collector.
unpack200 tools, and the Pack200 API in