Time is running out! Call for Code submissions due July 29 ›
by Dan Heidinga Published January 10, 2019
With the January deadline upon us for either migrating off Oracle JDK or paying license fees, you might be wondering what’s the right JDK for your business. Seems like there’s a lot of possibilities but how to pick?
Well, the answer is simple: OpenJDK with Eclipse OpenJ9.
OpenJDK with Eclipse OpenJ9 is built from two major open source communities: OpenJDK and the Eclipse Foundation’s OpenJ9 project. OpenJDK is the reference implementation of the Java platform and provides the base for most implementations of the Java platform. It’s a common place for everyone wanting to develop the class libraries and core APIs to collaborate. It provides a single set of APIs that are tested across multiple JVMs on multiple platforms ensuring that there’s a stable and consistent base for your application to target. Whether it’s the JDK 8 platform level or something newer, OpenJDK provides a consistent experience.
Why “OpenJDK with OpenJ9” then? Well, you definitely want the consistent stable API base that OpenJDK provides. You want the knowledge that your application will just run. You want to know your application will “just work.” But sometimes you want more than you get from Hotspot –- the JVM you get by default with the reference implementation. And the OpenJ9 JVM gives it to you.
Replacing the Hotspot JVM with the OpenJ9 JVM is like replacing your car’s engine – you have the same car just with better performance. OpenJ9 has a pedigree going back over a dozen years and has acted as a center of innovation delivering performance, hardware exploitation, and serviceability across numerous IBM products. Many of the benefits and features built into OpenJ9 continue to be the driving factors and key differentiators for today’s cloud native workloads.
Surprisingly, what matters most to cloud native workloads — fast startup, small footprint, and great peak performance are the same features that matter to desktop users. Desktop users want a stable platform that won’t consume all the memory on their systems, they want applications that start up quickly and are immediately usable, and of course, they want those applications to perform well.
OpenJ9 meets all those needs. The OpenJ9 code base has supported the full range of configurations from mainframe, to cloud servers, and all the way down to Java ME configurations. A maniacal focus on the tiny runtime footprint required to operate in an embedded space continues to this day. The developers continue to scrutinize the footprint of every new feature and ensure that memory is being used efficiently. Some of the design choices made in the embedded space continue to pay dividends today.
One example is how classfile metadata is stored within the VM. OpenJ9 uses a write-once, position independent format which allows metadata to be saved in shared memory just like shared libraries for native applications. This shared area, called the shared classes cache, also benefits startup time by allowing the JIT code to be saved and reused in later runs. The first time an application starts, it saves away some of the jitted code and metadata so that later runs can reuse that code and metadata to provide much faster start and ramp up. Why compile String, Object, ArrayList and all your application classes every time? Well, OpenJ9 doesn’t need to with this technology. Instead of waiting for the code to become “hot” enough to be worth compiling, OpenJ9 can start with the jitted code.
At this point, you’re probably asking yourself what’s the catch? I know I would be. And here’s the thing — there is no catch! OpenJ9 delivers the same (or better!) peak performance as other OpenJDK distributions and it does so while consuming ~60% less memory and also starting ~40% faster. That’s really incredible when you think about it.
Wondering if you can trust these claims? Turns out the benefits have been replicated by lots of users:
Second, @dadjeib and @adlleong‘s work on OpenJ9 just dropped mem footprint by 40% and gave a 3x improvement in startup time. In prod use at a Fortune 50 company already. https://t.co/V2P2O496nx— William Morgan (@wm) July 11, 2018
Second, @dadjeib and @adlleong‘s work on OpenJ9 just dropped mem footprint by 40% and gave a 3x improvement in startup time. In prod use at a Fortune 50 company already. https://t.co/V2P2O496nx
I can back up this claim. On a playframework webapp i’m working on, openj9 and openjdk 9 have near same max speed. openj9 uses .6x the ram.— Mark Hammons (@MarkHammons) October 7, 2017
I can back up this claim. On a playframework webapp i’m working on, openj9 and openjdk 9 have near same max speed. openj9 uses .6x the ram.
Testing @openj9 and HotSpot on simple app in Java 10 (@adoptopenjdk), @springboot 2, dummy GraphQL server, Actuator with Prometheus. Test is simple: start with least memory and be able to serve requests. OpenJ9 85MiB (working fine), HotSpot 115MiB (GC at limits). pic.twitter.com/pCDW3emD4O— Pavel Mička (@pavelmicka_xyz) July 4, 2018
Testing @openj9 and HotSpot on simple app in Java 10 (@adoptopenjdk), @springboot 2, dummy GraphQL server, Actuator with Prometheus. Test is simple: start with least memory and be able to serve requests. OpenJ9 85MiB (working fine), HotSpot 115MiB (GC at limits). pic.twitter.com/pCDW3emD4O
You’re probably thinking this is great for people who run Java 11 or whatever the current release is today. While it’s great for those users, it’s also great if you’re still on Java 8. The OpenJ9 community recognizes that not everyone can or even wants to migrate past Java 8 right now. We’ve committed to keeping Java 8 current for our users. We do this by using the same JVM across all the supported Java releases from Java 8 to 11 (LTS) and the current release (soon to be 12) — one source base compiled for each of the releases. That means you get the latest and greatest platform exploitation — new garbage collectors like the software-based concurrent scavenger with ultra-low pauses, better container ergonomics, improved JIT optimizations, and a JVM that keeps up with your hardware — regardless of which Java version you’re running. Our motto is “No LTS JDK release left behind!”
Ready to get the benefits of OpenJ9? Download a binary from AdoptOpenJDK –- the primary clearing house for stable, well-tested JDK binaries for your platform of choice: from Linux on x86-64 and other architectures like Power & s390, to Windows, and Mac OS X too, we’ve got you covered. The AdoptOpenJDK project builds and extensively tests each OpenJ9 release ensuring that you’ve got the best JDK to run your application.
Or if Docker is more your style, then pull one of the AdoptOpenJDK Docker images: docker pull adoptopenjdk/openjdk8-openj9
docker pull adoptopenjdk/openjdk8-openj9
Do your corporate policies require a support contract for software? Not a problem! IBM offers support for the OpenJ9 builds from AdoptOpenJDK through the IBM’s support offering for OpenJDK.
Great performance, better memory efficiency, and optional support from a major vendor you can count on –- everything you can want in one package.
An interview with Marek Sadowski, an expert in containers, Kubernetes, and server-side Swift who started out as a full stack…
Learn about default arguments, named arguments, nullable values and how to use them as function arguments, smart casts, and more.
Understand why you should learn Kotlin and how this learning path will help you.
Back to top