Interview series with Java influencers — Part 2

JDK 11 – End of road for Java EE & CORBA modules and Nashorn JavaScript Engine. What’s left to axe?

Gabriela Motroc
© Shutterstock / NLshop

In the first part of this interview series, we invited seven Java influencers to talk about the new six-month cadence and the dangers of release fatigue. Now it’s time to talk about their favorite Java 11 feature(s) and weigh in on everything that has been axed [or deprecated].

A “lighter” JDK 11: We’re saying goodbye to Java EE & CORBA modules and Nashorn JavaScript Engine

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].

With all this “spring cleaning,” one cannot help but wonder: Who’s next? Our influencers may be onto something but let’s not spoil the surprise. 

In the first part of this interview series, we invited a few Java influencers to talk about the new six-month cadence and the dangers of release fatigue. Now it’s time to talk about their favorite Java 11 feature(s) and weigh in on everything that has been axed [or deprecated].


7 answers: Describe your favorite Java 11 feature.

Meet the Influencers

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

Jessica Kerr (@jessitron) is Lead Engineer at Atomist.

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: Two very different things. I can’t just select one.

First and most important is the inclusion of the Flight Recorder (JEP 328) together with the now open sourced Mission Control; this will bring a lot of power to developers that need performance and troubleshooting help.

My second choice is JEP 318: Epsilon garbage collector. This will be very effective when it comes to distributed systems that consist of a lot of super short-lived services.  

Jessica Kerr:  I’m tickled by Epsilon, the no-op garbage collector. Along with Flight Recorder and heap sampling, the JVM is becoming more introspectable and testable. The no-op garbage collector lets people find their own latency problems, disambiguated from GC pause. It also lets short-running programs dispense with the ongoing cost of GC.

In a containerized world, “The JVM shut down” is not a disaster: Kubernetes will restart it.

I don’t feel the changes to the language are that significant for this release.

Guillaume Laforge: The most visible feature is certainly the new var syntax for declaring local variables.

I’ve always enjoyed using the “def” syntax in Apache Groovy, so I’m happy to have something similar in Java as well. Be sure to keep using easily readable and understandable variable names, and it’s gonna be great to be able to just use “var” to declare the variable.

Lukas Eder: JEP 330: “Launch Single-File Source-Code Programs”. This appears to be just a small change, but for newbies to learn Java, it is of great value, just like the jshell.

I like the little things that make everyday work easier. Sure, it’s great that project Amber and Valhalla exist, for the big stuff. But the little things are what help people with their everyday work. Have I mentioned that I’m super excited about JEP 326?  

Josh Long: Raw String literals which give me multiline Strings and methods to support them, like `repeat()` and `stripLeading()`. This is ideal for text processing.

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

Eberhard Wolff: I think the Flight Recorder and the low-overhead heap profiling might be interesting. More features for operations and better visibility into the JVM are very helpful. Often such features are overlooked because they do not change the language and are therefore less relevant to developers. However, I don’t feel the changes to the language are that significant for this release.

Martin Thompson: I’ve seen virtually no adoption of Java 9 and 10 so I see 11 as a release which rolls up all three. There are a number of refinements to the platform which can enable important changes in future releases such as thread checkpoints that can make G1 write barriers more efficient and fix the horror of revoking a bias lock.

If I was to pick a single feature it would be VarHandles which are a large step towards eliminating the need for the use of sun.misc.Unsafe in concurrent code. Before VarHandles, some concurrent algorithms were not possible in Java without resorting to using Unsafe. Very few developers need to use these features but many use libraries built on them.

Quentin Adam: Speaking about Java 11 as a platform, the most exciting feature is ZGC, the new low latency and concurrent garbage collector. It will solve a lot of problems on huge load and massive installation of big data software like Hadoop, Hbase and Kafka. This kind of software, when they are under heavy load, hence heavily using Heap at large volume, rely dramatically on the GC. It will unlock new performance levels and capabilities for the JVM world on all the big data market.

It also shows that JVM is still leading the way in GC research and innovation. On this, addition of Epsilon, the no-op GC (the GC does nothing, very useful for short living program like CLI command, and way faster) is showing the modularity of GC on Java platform.

Speaking of Java 11 as a language, the new syntax in lambda for local variables is really nice, allowing to use implicit types, it makes lambda reading much easier and will drive to use it more in java, which is a great thing.


Java 11 will be “lighter” in the sense that JavaFX will soon be decoupled from the JDK, we’re saying goodbye to Java EE modules and Nashorn JavaScript engine will be deprecated. What’s left to axe?

Markus Eisele: I’d call it a natural progression. We all badly want the core runtime to be small enough to be run on a variety of devices and also have a tremendously fast startup. Distribution sizes have to go down too to make it easier to embed the JDK.

If the OpenJDK focuses on hooks and groundwork (e.g. Flight Recorder APIs + external Mission Control tooling), the ecosystem can more easily evolve and extend beyond what’s possible within the OpenJDK itself.

Jessica Kerr: We used to use Nashorn before its deprecation was announced, and now we run Node in production – a circumstance that helps us appreciate the professionalism of Java and the JVM even more. It makes sense to decouple the JDK from the separate pace of movement of other ecosystems like JavaScript.

Like microservices, this is a decoupling of release schedules that gives the JVM more flexibility.

Guillaume Laforge: I’m actually not necessarily super happy to see Nashorn go, as it was a nice way to add built-in scripting in a Java app. But so be it, and it’s pretty easy to add other alternative language solutions like Apache Groovy anyway. But it sounded a useful feature to have built-in.

Why did we ever have a JavaScript engine bundled into the JDK?

I think Corba should be removed too, which is a good idea, as its usage is rarely seen anymore in the wild these days.

Perhaps ultimately, the AWT / Swing APIs should be moved outside of the JDK, but I’m a bit afraid of the impact, in particular, if it means it becomes unmaintained, and then we can’t have nice UI toolkits anymore for client-side applications like IDEs (I’m thinking tools like Eclipse IDEA for example, what’s happening if Swing becomes unbundled, and worse, unmaintained?)

Lukas Eder: Swing, AWT. It’s amazing that a platform that is mainly used for “headless”, server-side stuff contains big rich desktop application libraries out of the box.

Also, if some parts of the java.desktop module could be refactored into their own modules, that would be great. I’d love to see a java.beans module, containing all the JavaBeans related stuff that has great use outside of java.desktop. I’m sure the Spring folks would appreciate that as well.

SEE ALSO: JAX Magazine is out: It’s onwards and upwards for Java

Josh Long: Good question! I haven’t given it so much thought. I don’t use AWT/Swing a lot. So, maybe them?  But would those benefit from extracted and developed in isolation? I’m not so sure…

I’m happy now that the CORBA modules are gone.

Eberhard Wolff:  I am not sure how important it is to remove modules from the JDK. In the end, it just means that the JDK is a somewhat larger download. With the module concept in Java 9, developers can already remove unneeded modules and build a custom JDK. Of course, it might make sense for Oracle to remove these modules so they can work on more important features.

Martin Thompson: What’s left to axe? Interesting question. A better one is, why did we ever have a JavaScript engine bundled into the JDK?

Quentin Adam: It’s a good news. The path to JDK modularization (project Jigsaw) has been long, and complicated, but finally it’s here! The next step is to use it and start to move part of the JDK to modules, and profit for all the hard work done. It will help to remove the old stuff, and move them to modules, graphics stuff not needed on a server, server stuff not needed on a client… And it will allow creating new modules to extends the JDK with features more easily.



Next week, we’ll weigh in on the importance of Java 11 [and if it can convince developers that it’s “safe” to drop Java 8]  and the (shocking?!) end of Nashorn JavaScript engine. 

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