Faster release allows for innovation

JAX London, 08-11 October 2018
The Conference for JAVA & Software Innovation
4
Sep

Running outdated Java is risky

running outdated java is risky

Find out why GraalVM is one of the most important innovations in Java space. In this interview, Eberhard Wolff talks about the building anticipation for Java 11.

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 think this is a great change. It allows for much faster innovation. At the same time, it provides a clear and reliable path for Java into the future. Also it means that we won’t have to wait too long for new features. Once a feature is done, it can be put in the next release that is just a few months away.

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

Developers are usually eager to try out new features. So I don’t think the new release cadence is going to be a huge problem for developers. However, not every organization will roll out a new Java version into production every six months. Even now there are often outdated Java version in production that are no longer supported. This happens even though running an outdated Java version in production is risky. There are not even security fixes. Probably the commercial agenda behind the more frequent Java releases is to increase the number of outdated JVMs in production. Those would need to be covered by support contracts. We’ll see how this works out for Oracle. It seems quite a few are already used to the risk of running outdated Java versions.

JAX enter: Describe your favorite Java 11 feature.

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.

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?

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.

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 Java 11 has long term support, it is likely that even conservative developers will eventually migrate to Java 11. The new features are not that huge from a developer’s perspective so I don’t think they provide enough motivation to migrate to a new version immediately.

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?

We’ll see. Outdated Java versions in production are actually quite common. Of course it would be great to get free supported Java version for a much longer period of time. However, to continue Java’s success it must be a commercially viable platform. That means there must be some revenue to justify the investments. So I think it is fair to ask for money for the additional support timespan. Also there is still the OpenJDK so the community can work on the problem if they are not pleased with what Oracle does.

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?

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

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

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.

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

Serverless has different requirements. The code is launched on demand so startup time is important. The JVM’s JIT compiler is optimized for a system that runs for a long period of time. Over time the JIT will compile more and more of the code to machine language and introduce other optimizations. This does not pay off with serverless at all. Also the memory consumption is more important with serverless as more memory increases costs. Some of Java’s garbage collection algorithms consume quite a lot of memory. I thought these problems are so fundamental that they cannot be solved. However, the GraalVM compiles the code ahead of time to machine code and reduces startup time significantly. So it seems that Java will be a much fit for serverless in the future – and that is great news!

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

As I said I think the GraalVM is a very important new technology. So that is pretty high on my wishlist. However, the JDK Enhancement Proposals for Java 12 don’t include the GraalVM and it might actually stay a separate project.

Thank you!

Behind the Tracks

Software Architecture & Design
Software innovation & more
Microservices
Architecture structure & more
Agile & Communication
Methodologies & more
Emerging Technologies
Everything about the latest technologies
DevOps & Continuous Delivery
Delivery Pipelines, Testing & more
Cloud & Modern Infrastructure
Everything about new tools and platforms
Big Data & Machine Learning
Saving, processing & more