Frequently asked questions
Is Eclipse OpenJ9 a replacement for OpenJDK?
No. Eclipse OpenJ9 is a Java™ virtual machine (JVM), the engine that runs Java applications, whereas OpenJDK is a complete development kit that contains other components, like the Java class libraries, as well as a JVM. By default, OpenJDK builds with a JVM called Hotspot. Put simply, OpenJ9 is an alternative JVM that you can include as part of an OpenJDK binary.
Is Eclipse OpenJ9 the same as Hotspot?
Hotspot and Eclipse OpenJ9 are both Java virtual machines that can be included in an OpenJDK build, but each has different capabilities. Depending on the build process you follow, you can build an OpenJDK binary that includes either Eclipse OpenJ9 or Hotspot.
What does the J9 in OpenJ9 stand for?
To clear up a common misconception, J9 != Java 9. If you are interested in hearing about how it got its name, read this blog post.
Why use Eclipse OpenJ9 instead of the default JVM?
If you are looking for an enterprise class runtime environment for your application, build OpenJDK with Eclipse OpenJ9. This high performance, scalable virtual machine is at the core of many IBM enterprise software products, so it has a great pedigree.
You can also tune OpenJ9 to further improve the performance of Java applications for specific scenarios. For example, you can switch garbage collection policies to manage memory for different types of workload.
What license is Eclipse OpenJ9 made available under?
The project license is Eclipse Public License 2.0 and Apache License, Version 2.0 (you can choose), but the EPLv2 license has a secondary compatibility for the GPL v2 that is used by OpenJDK. You can combine the two projects and use them together (as OpenJDK's GPL v2 of course). The full license is documented in the LICENSE file and also summarized at the top of virtually every file in the Eclipse OpenJ9 GitHub repository.
Which OpenJDK versions and which platforms is Eclipse OpenJ9 supported on?
How easy is it to migrate to OpenJDK with Eclipse OpenJ9?
Most Java applications should run without changing anything. However, if you are using a runtime environment that embeds the HotSpot VM and you set a lot of command-line options when you start your Java application, read the article Moving to OpenJ9.
How can I discuss ideas and provide feedback to this community?
There are a number of ways that you can engage with the OpenJ9 community:
- Join our OpenJ9 slack workspace where you can collaborate directly with developers and other contributors on the project. To join slack, request an invitation.
- Join the Eclipse mailing list and post a message to our development community.
- Come along to our regular hangouts, where you can speak to OpenJ9 developers directly, ask questions, and share your experiences. Schedules and agendas for hangouts are posted in the #planning channel of the OpenJ9 slack workspace.
- Create an issue in our OpenJ9 GitHub repository.
- If you want to keep up to date with the latest news from the project, why not follow us on twitter, @openj9.
Why did IBM contribute their J9 virtual machine to the Eclipse Foundation?
IBM is publicly committed to bringing innovation into the open source development community. Contributing the J9 virtual machine, which has been at the core of IBM SDK, Java Technology Edition for many years, demonstrates that commitment. The OpenJ9 virtual machine is itself based upon core technology components of the Eclipse OMR project, which was contributed by IBM to the Eclipse Foundation in 2016. IBM continues to invest resources in both Eclipse OpenJ9 and Eclipse OMR to ensure that their enterprise products can take advantage of the latest hardware technologies.
Why do I clone from https://github.com/ibmruntimes/openj9-openjdk-jdk8?
It is necessary to apply patches on top of OpenJDK for it to function correctly with Eclipse OpenJ9. The https://github.com/ibmruntimes/openj9-openjdk-jdk8 repository contains a recent version of OpenJDK, taken from the OpenJDK repository with additional fixes applied.
I think I've found a performance issue. How can I be sure?
Firstly, we appreciate you taking the time to evaluate the performance. We would like to encourage you to open a Github issue if you notice an area where you think we can improve. Please tell us about your application, the Java command-line options that you used, and any other relevant information to help us re-create and investigate the issue.
While we are constantly striving for good performance in as many cases as possible, there are reasons why performance characteristics might be different when running OpenJDK with the OpenJ9 JVM, compared to other JVM implementations.
One important reason is because performance is not such a simple thing; performance is a generic phrase that can be used to refer to different metrics such as throughput, footprint, startup time, ramp up time, response time, scalability, and so on. When faced with multiple metrics, tradeoffs must often be made. Unsurprisingly, independently developed JVMs can engineer towards very different tradeoffs. For example, better footprint or startup might come at a cost to throughput, or vice versa.
Most traditional Java benchmark suites focus on application throughput or elapsed time to the exclusion of everything else. While these are undoubtedly important things to measure, changing industry trends, like the growing use of cloud computing platforms, mean that other metrics such as footprint, startup, or throughput with security enabled are also gaining importance. Hence, to evaluate the performance of a JVM, a broader view across different metrics should be taken. We also think it is important when evaluating enhancements to JVM technologies that we don't focus too much on a single metric without accounting for the impact to other metrics.
There is a second, more pragmatic reason why performance characteristics might be different when running OpenJDK with the OpenJ9 JVM, compared to other JVM implementations. For nearly two decades, the OpenJ9 development team has focused on the broad performance requirements of large enterprise applications. As a result, less development time has been invested in tuning the JVM for many of the common Java benchmark suites, compared to other JVM implementations. We are aware that performance gaps for OpenJDK with OpenJ9 are being reported when running some of these benchmark programs.
Microbenchmarks, by their nature, are designed to accentuate performance gaps by narrowly focusing on the area they are testing. Because of this tight focus, even one missed opportunity can lead to a substantial performance difference. Optimizing a JVM for these kinds of programs is often a balancing act between delivering maximum performance and being careful not to develop optimizations that might turn out to be irrelevant, or even potentially harmful, for the performance of real world applications.
At the end of the day, whether we need to revisit a particular tradeoff decision, optimize a microbenchmark pattern, or just fix a plain old performance bug, these are all opportunities to improve our JVM. We welcome reports of performance problems you encounter in Java programs, no matter how large or small. And since we're an open source project, you can also suggest improvements or contribute patches yourself!