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

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

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

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.

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.

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.

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.

In a cloud native world enamored with microservices and serverless, meet Quarkus – Java’s brilliant response to technologies like Node.js, Python and Go that had proven quicker, smaller and arguably more nimble. Donload your free beginner's tutorial written by JAX London speaker Alex Soto.

17 features for JDK 11

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.

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