JAX enter: How do you feel about the new six-month cycle and the new rhythm? After all, Java 10 was the fastest release in Java’s 23-year history and now we’re already 2 months away from Java 11.

I feel it is a very good move to have a regular release train. Many useful features got pushed back due to the delays introduced by Jigsaw/Modules which has set back Java compared where it could have been. The new schedule means smaller features can make the next release while more complex features can be developed in parallel to the release schedule until they are ready. We are seeing this now with Values Types proving more complicated than expected yet they are not holding up others things as Value Types get developed under the Valhalla project.

JAX enter: Do you think the new release cadence will lead to fatigue or is it just keeping developers on their toes?

I do not expect the cadence to drive adoption. Features which enable delivery are what drives adoption based on what I’ve seen over the last 3 decades in software development. What goes into Java is more important than how often we get releases. Larger organisations I’ve been talking to see the LTS releases as similar to the old release cadence with the likelihood of it being more predictable.

The much larger question is if future releases are to be more difficult to upgrade to. Many in the enterprise space struggle to upgrade when things break. This is a complex issue that goes way beyond an organisations own code base. Enterprise code is often difficult to change due to a lack of CI and automated test suites plus the authors have often moved on. This gets more complex given how dependent Java is on the ecosystem of open source libraries. Many of these libraries are developed by enthusiasts with little or no commercial support. As an open source developer it is difficult supporting many versions especially without natural support for multi-version builds and pre-processors. This is something which needs to be considered in the evolution of Java otherwise it could self destruct. Modules have made this more difficult.

JAX enter: Describe your favorite Java 11 feature.

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 with resorting to using Unsafe. Very few developers need to use these features but many use libraries built on these features.

JAX enter: 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?

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

JAX enter: A lot of developers are still using Java 8. What does this mean for Java 11 adoption? Do you think Java 11 will be important or big enough to make them want to drop Java 8?

As mentioned above, Java 11 has some nice refinements but no killer feature to drive adoption. Java 5 had Generics and Java 8 had Lambdas. In the history of Java those were the only 2 releases I seen people get excited about. Without a major feature then people need a very smooth upgrade path otherwise they will wait. Right now I’m seeing people completing their migration to Java 8 and they have little appetite for any upgrades that are not easy.

JAX enter: Speaking of Java 8, public updates will remain available for individual, personal use through at least the end of 2020 but business users won’t be that lucky — the ‘public updates’ tap will be turned off in January 2019. A lot of Java developers believe that this decision is “ruining Java”. What’s your take on that?

This is an interesting change in strategy for Java. Java as a platform has always been freely available which is one of the reasons I believe it has been a success. I can see the need for Oracle wanting to commercially benefit from Java but they need to be careful and choose wisely. Given .Net Core is now available on Linux and freely available then it is a risky time for Java. C# is currently a more elegant language but it does not have the ecosystem of Java. Microsoft are taking steps to open .Net and expand its ecosystem and it proving a nice platform for Serverless. Java is difficult to influence from outside Oracle and is becoming less available with the proposed changes.

JAX enter: 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?

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

JAX enter: How do you feel about ZGC? Can it make latency a non-issue for Java applications?

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 Redhat and Epsilon No-Op Garbage Collector providing a baseline to compare GC implementations against.

JAX enter: Demand is growing for serverless platforms. Will serverless begin a major reshaping of Java?

To compete in the Serverless space Java will have to improve its startup time and footprint. Work is being done in the area but it has a long way to go when competing with footprint and startup time of other languages.

JAX enter: What features would you like to see in Java 12?

Most systems are now distributed and thus network comms are an important feature. We are getting some progress with project Loom but I feel this is the wrong strategic direction. Most application developers use a library when making network calls so they don’t use the networking APIs directly. The library developers of messaging and comms systems are crying out for better NIO libraries to use the latest features like DPDK or more direct integration with Windows or Linux APIs. Networking library developers are comfortable with non-blocking APIs and don’t need this to be hidden from them. In addition, Serverless suggests event driven designs which are triggered from the network. This feels like an overlooked area for Java.