Interview series with Java influencers — Part 4

It’s time to put a spotlight on ZGC and dim Nashorn’s star: Java influencers weigh in

Gabriela Motroc
© Shutterstock / Lantica

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.

First came the news that we’re saying goodbye to Java EE & CORBA modules, then it became clear that JDK 11 represents more than just the end of the road for Java EE modules — it’s also the end of the road for JavaFX — kind of, since it will now be available as a separate module, decoupled from the JDK. Just a few months later, we discovered that the hunting season was not over and that the latest victim was Nashorn JavaScript Engine, which was first incorporated into JDK 8 [and released in March 2014].

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?


7 answers: Nashorn JavaScript engine will soon be deprecated and the most viable alternative seems to be GraalVM. What does GraalVM have that Nashorn doesn’t? Should Nashorn be kept alive by the community?

Meet the Influencers

Markus Eisele (@myfear) is the Director of Developer Advocacy at Lightbend and a Java Champion.

Guillaume Laforge (@glaforge) is Developer Advocate for Google Cloud Platform, Apache Groovy PMC Chair at The Apache Software Foundation and Java Champion.

Lukas Eder (@lukaseder) is the founder and head of R&D at Data Geekery GmbH, the company behind jOOQ and a Java Champion.

Josh Long (@starbuxman) is the Spring Developer Advocate at Pivotal. He is the author of 5 books and 3 best-selling video trainings. He is also a Java Champion.

Eberhard Wolff (@ewolff) is a Fellow at INNOQ and a software architect.

Martin Thompson (@mjpt777) is a consultant, trainer, and coach specializing in designing high-performance and low-latency systems. He is also a Java Champion.

Quentin Adam (@waxzce) is the CEO of Clever Cloud.

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.

Nashorn, on the other side, was designed to be a JavaScript engine on the JVM. I haven’t seen a lot of production systems built on it and to me, it always has been a very distinct and complete test for the new invokedynamic call-site that was introduced with Java 8.

My expectation is that GraalVM will deliver better results when running JavaScript code than anything that has been sitting on top of HotSpot. For sure, there is an opportunity for the community to take it over but I am not sure that it’s worth it.

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.

SEE ALSO: Nashorn JavaScript Engine deprecation: “This might increase the importance of Rhino again”

Josh Long: I think Nashorn should be kept alive by the community, but I don’t know that it will. JavaScript is by any measure one of the most prolific languages and yet Nashorn hasn’t thrived, even under Oracle. Developing a language is hard and depends on specialized skills. It is not the work of the commons. There are very few enthusiastic and talented folks,  like JRuby’s Charles Nutter, doing the work for the love of the work.

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.

Eberhard Wolff: The JDK Enhancement Proposal to deprecate Nashorn actually asks how many developers are using Nashorn. So it seems they have reason to believe that Nashorn isn’t that popular after all. But they are open to change their reasoning if it turns out that Nashorn is actually popular. It is also not clear to me why a JavaScript implementation should be part of the JDK. There are other scripting languages available as 3rd party libraries and that should be fine for JavaScript, too. So I guess 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.

Martin Thompson: I don’t have much involvement with JavaScript on the server side.

Quentin Adam: Modules in the JDK is a good thing, and splitting core from non-essential stuff is important. Considering the JavaScript language inside the Java ecosystem, the vision was to use it as a scripting language. But today, this role is more devolute to Apache Groovy, and the current usage of JavaScript on top of JVM does not require it to be embedded in the core of the platform.

As a technology project, Nashorn is a very good piece of software, and I really like it, I even built a server-side JavaScript application server and build tools on top of it years ago. But times go and it will be maintained only if people need it day to day.


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.

SEE ALSO: ZGC: Making Java a more attractive platform for a wider set of applications

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.

SEE ALSO: ZGC joins the party: JEP 333 targeted to JDK 11

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:

181: Nest-Based Access Control

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.

309: Dynamic Class-File Constants

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.

315: Improve Aarch64 Intrinsics

Improve the existing string and array intrinsics, and implement new intrinsics for the java.lang.Math sin, cos and log functions, on AArch64 processors.

318: Epsilon: A No-Op Garbage Collector

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.

320: Remove the Java EE and CORBA Modules

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.

321: HTTP Client (Standard)

Standardize the incubated HTTP Client API introduced in JDK 9, via JEP 110, and updated in JDK 10.

323: Local-Variable Syntax for Lambda Parameters

Allow var to be used when declaring the formal parameters of implicitly typed lambda expressions.

324: Key Agreement with Curve25519 and Curve448

Implement key agreement using Curve25519 and Curve448 as described in RFC 7748.

327: Unicode 10

Upgrade existing platform APIs to support version 10.0 of the Unicode Standard.

328: Flight Recorder

Provide a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM.

329: ChaCha20 and Poly1305 Cryptographic Algorithms

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.

330: Launch Single-File Source-Code Programs

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.

331: Low-Overhead Heap Profiling

Provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI.

332: Transport Layer Security (TLS) 1.3

Implement version 1.3 of the Transport Layer Security (TLS) Protocol.

333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)

The Z Garbage Collector, also known as ZGC, is a scalable low-latency garbage collector.

335: Deprecate the Nashorn JavaScript Engine

Deprecate the Nashorn JavaScript script engine and APIs, and the jjs tool, with the intent to remove them in a future release.

336: Deprecate the Pack200 Tools and API

Deprecate the pack200 and unpack200 tools, and the Pack200 API in java.util.jar.

Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Inline Feedbacks
View all comments