The Blog



Oracle Code One 2018 talk


Let’s be honest. Running a Java application in the Cloud is not straightforward. Getting the best performance for your application can be challenging. Cloud environments have a different set of economics and a different set of operational demands from the traditional “on-prem” data center we are all used to. Do you deal with these differences by modifying some or all of your application, or do you just start again and create a new solution?

Cue the term “cloud native.”

Whatever your choice, the outcome must be an application that can be easily scaled, easily deployed, highly available, resilient, and economic. Cloud native means exploiting the benefits of cloud, not battling against it.

What does that have to do with the JVM?

Historically, Java applications have been designed to be long-running, efficient, monolithic applications. We’ve been willing to trade startup time for throughput. The expectation is that the application will persist for months and years. This approach has driven the evolution of the JVM. Whether GC models, JIT compilation, or memory models, the JVM has adapted and tuned to provide the optimal environment.

A cloud-native application has almost completely opposite expectations. It expects to be short-lived and be microservice-oriented. It demands an instant-on, always-available approach that uses the least amount of memory.

Can we retune the JVM? The future of Java hinges on our ability to support both the existing application model as well as the new. Unfortunately, the challenge is even greater than a wholesale rewrite. The evolution of cloud hasn’t finished. We are still deciding what the key elements of a cloud application will be and which element of the stack will provide which capability: is it microservices, is it serverless, is it containerized, is it mesh-based? How do we use AI, machine learning, and even new hardware in our cloud-native applications?

Our challenge as a community is to ensure Java is not left behind, and that means having a JVM that can keep up with the pace of innovation in cloud and evolve with it.

Introducing Eclipse OpenJ9

In September 2017, IBM contributed its JVM technology to the Eclipse Foundation. Why? Because these modern Java problems can’t be solved by the few – we all need to work together to take Java in new directions and keep Java successful. Having only one JVM codebase to work from is constraining. Having two codebases, two hardened, proven JVMs designs to experiment with is much, much better.

A great starting point

We think the Eclipse OpenJ9 JVM has design features that make it a much better starting point for cloud-native applications. As we explore and evolve the world of cloud, we know OpenJ9 can evolve with it.

In this session, we’ll look at the design of Eclipse OpenJ9 to explain why we think this, and we’ll show off the immediate benefits cloud-native applications get by choosing Eclipse OpenJ9.

50% saving in memory usage, anyone?