While going over a java book I came across this phrase:
Different JVMs can run threads in profoundly different ways.
While it's completely understandable to me that code can behave differently depending on the underlying JVM implementation, it does bring up the question.
Why are there multiple different implementations of JVM in the first place?
Why might I, as a developer be dissatisfied with the official JVM implementation that Oracle provides and decide to build up a different one?
Why might I, as a developer be dissatisfied with the official JVM implementation that Oracle provides and decide to build up a different one?
Which one? Oracle has at least three different official JVM implementations!
A couple of reasons why one might develop a JVM implementation are:
Java is not a specific product or binary. The Java platform is defined by a set of specifications for the language and the JVM, plus JSRs and JEPs.
You said:
the official JVM implementation that Oracle provides
There is nothing "official" about any particular Java implementation. Any implementation that fully implements the specs can run any app written for Java.
The three implementations provided by Oracle are not any more "official" than any other vendor’s implementation.
To understand more detail about Java implementations and vendors, read the white paper: Java is Still Free.
The word “Java” is trademarked by Oracle. An implementation wishing to use that trademark must come to terms with Oracle. In the past those terms included passing an extensive suite of automated tests, plus presumably paying a fee.
Most of the vendors providing a Java implementation choose to not use the Java™ trademark, instead using the OpenJDK terminology when labeling their distribution.
And speaking of testing suites, the AdoptOpenJDK project has announced their own comprehensive testing suite to be used for builds of OpenJDK. Known as AQA, pronounced "aqua". Their goal to provide tests that are open-source, transparent, diverse, robust, and freely available.
Nowadays, every Java implementation I know of is based largely, if not entirely, on the OpenJDK project.
FYI, Oracle has declared that “There will be zero differences between the OpenJDK and the Oracle JDK”. The company has even open-sourced their previously commercial tools such as Flight Recorder and Mission Control through the OpenJDK project.
The OpenJDK project produces only source code. You can make your own build from that source code.
Most folks would prefer to get an installer or binary already built. To satisfy that need, several of the vendors listed below have banded together with others to support the AdoptOpenJDK project, now known as Adoptium.
Some of the vendors provide the Adoptium builds directly to their customers. Some vendors may add value to the Adoptium builds. And of course some vendors produce their own builds entirely separate from the Adoptium project.
Adoptium is a good place to start if you are new to Java and have no reason yet to select a particular vendor. Later, if you develop reasons to select a particular vendor such as wanting to purchase support, you can always switch. Your app and your tools will work with any implementation of Java that complies with the Java specifications.
Originally backed by the London Java User Group, the project is now run by the Eclipse Foundation. See the About page of the AdoptOpenJDK/Adoptium site for more details.
The Answer by Jörg W Mittag is correct. I would add a few more considerations: price, support plans, and convenience.
Over the years, there have been many Java implementations. They have varied in price. Some are free-of-cost, and some require a fee.
Take, for example, Oracle’s popular Oracle JDK product. As of April 16, 2019, Oracle changed the licensing terms. A fee is now required for use in production, while still free-of-cost for development, testing, and such. People unwilling to pay that fee for use in production must either (a) use another Oracle product without a fee such as jdk.java.net, or (b) look to an alternative vendor such as those listed in the flow chart below.
Some users of Java want the security of having a vendor to call when a problem arises. Some want a promise that a critical security vulnerability or technical bug will be patched as quickly as possible (as discussed on another Question). For either of these reasons, some people may want to purchase a support plan.
Some vendors of Java implementations provide such a support service, and some do not.
Some people with an established relationship to a particular vendor might enjoy the simplicity of obtaining Java from that same vendor.
For example, Red Hat / IBM provides their own downloads of a Java implementation based on the OpenJDK while at the same time also actively supporting the AdoptOpenJDK project which also distributes builds and installers of OpenJDK.
Here is a flow chart I created to walk people through the various options to consider in choosing a vendor for their Java implementation.
And here is a list of possible motivations one might have for choosing a vendor.
JVM is an abstraction. It's a software layer specifically designed to allow the Java language to be platform-agnostic by relying on the existence of a specs-compatible runtime engine "everywhere."
But ... one size does not fit all. If you're trying to "wedge" Java into a very small environment, such as an underpowered (but cheap) Android-style mobile phone, you might have to "bum code" very considerably more than Official Oracle™ found it necessary to do. You might need to develop a JVM implementation that never existed yet.
And so, that's why there are many JVMs. They are architecture- and situation-specific, so that Java doesn't have to be.
It’s called competition. If I think I can create a JVM that is sufficiently better and make money selling it, that’s what I will do.
