tl;dr

Every six-month release of Java is of the highest quality, production-ready, subjected to more testing than any other general-purpose development platform. Choose from any of several JDK/JRE vendors.

• If you deploy often, use the freshest release available every March & September.
• If you deploy less often, use the Long-Term Support (LTS) version released every two years.

Depending on your needs, consider purchasing a support contract from any of several vendors.

Every version of Java is stable and reliable

The Java specifications are updated on a six-month cadence, per the “release train” model used for several years now.

• Finalized features are included.
• Features not yet complete are held back for possible inclusion in the next release, six months later, when the next train leaves the station.
• Preview features are completely implemented and production-ready but are disabled by default, hidden behind feature flags, as they are subject to change.

Implementations of the Java specifications follow this same six-month cadence. (See FAQ.) The most important of the implementations is the open-source codebase at the OpenJDK project. However that project publishes only source code, not binaries nor installers.

For JDK/JRE products delivered as binaries or installers, choose from any of several vendors:

• IBM
• Red Hat
• Adoptium by the Eclipse Foundation
• Amazon
• Azul Systems
• Microsoft
• BellSoft
• Oracle
• SAP
• … and more

Most of the JDK/JRE products from various vendors are based largely, if not entirely, on the OpenJDK codebase.

All of these JDK/JRE products are thoroughly tested. Nearly all have been tested by the Technology Compatibility Kit (TCK). Some are also subjected to the Eclipse AQAvit test suite.

So every JDK/JRE product from any of these vendors is the highest quality and production ready. You can always deploy the latest release of Java.

Your confusion may come from the fact that most releases of Java are supported for a short time only. The support period typically runs from launch to a few months after the succeeding version’s launch, for a total of about nine months. That is generally the case, though each vendor makes their own support policy. Any vendor may offer extended support, perhaps for a fee.

Long-Term Support (LTS) versions

Every few years a particular version of Java may be designated by the vendors as a Long-Term Support (LTS) version. Historically, the community of JDK vendors has followed the lead of Oracle in making this LTS declaration. So we have seen an LTS every three years in the past, and every two years currently. The LTS versions include:

• Java 8
• Java 11
• Java 17
• Java 21
• Likely Java 25

See Java version history at Wikipedia for details.

Be very clear though: These LTS versions are not any more reliable or stable than the other versions. Every version of Java is feature-complete, and of the highest quality. The LTS versions are not any more important or better than the short-lived versions. The LTS designation is an arbitrary one, based on the calendar, not on quality.

OpenJDK source code and the JDK/JRE products are perhaps the most thoroughly examined and well tested software ever released (outside of specialty fields such as aerospace or military).

Development & deployment choices

Many Java developers make a habit of developing and/or testing with the latest version of Java to ensure compatibility. Some developers limit deployment to LTS versions only, while others with rapid releases may choose to always use the latest version.

The choice is yours to make based on your development and deployment situation, without concern for the quality of any particular Java version.

How does LTS work?

For the nitty-gritty on exactly what LTS means in the Java community, see this article & video by Nicolai Parlog.

To understand more about the Java ecosystem, see the white paper by pillars of the Java community, Java Is Still Free.

Because they switched to a new release model which allows for them to get new features out faster.

Same thing happened when Firefox and chrome switched to a timed release model. People bitched about version numbers but slowly got use to the fact that "I don't really care that this is firefox 82".

From an organization standpoint, this has been great for the Java getting features out. It used to be that they'd say "Ok, we are going to target key feature X for java Y". The problem with that is nearly all project development got devoted to that feature and ultimately "when" java would go out was completely unknown. Further, releases where crazy times for JDK developers.

With the new model, they've been able to work on a lot more features in parallel. A ton of usability features made it in (records, pattern matching, string literals) which never would have made it in the old model. Further, it's allowed them to slowly walk in huge features (Valhalla, loom, etc) making pre-emptive changes needed to support massive changes in the future.

Post Java 9, the upgrades have been a breeze. Honestly, I almost wish they'd move to an even faster release model to really force people to stop caring so much about these version numbers. Rust does a release every 6 weeks and I think that works great. Nobody cares that it's now Rust 1.50 or whatever.

Later Java runs earlier apps

You said:

JAR files will not open and say that they were made using a more recent version

An implementation of Java will be able to run most any Java app built with earlier versions of Java.

For example…

If you compile your app using Java 8, you will almost certainly be able to run that app with Java 8, Java 9, Java 10, Java 11, and so on, all the way through to today’s Java 25.

This compatibility is one of the highest priorities for the Java team at Oracle, and a large part of Java’s success. Breaking changes have been kept to an absolute minimum. “Move fast and break things” is not their motto, just the opposite.

Going the other direction…

If you compile your app using Java 20, you will not be able to run that app with Java 8, Java 9, Java 10, and through to Java 19. A later version of Java and its compiler will be using features that did not exist in those earlier versions. So, of course, older runtimes cannot execute later apps.

If you compile with 20, you need to run with 20 or later (20, 21, 22, 23, 24, 25+).

Java Release Train

Java 25 is current now in 2024-09.

Java releases arrive on a regular schedule, like a train, every six months, Autumn & Spring. Any feature not yet production-quality gets bumped to the next release, like a passenger missing a train boards the next one.

LTS

Versions 8, 11, 17, 21, & 25 are designated as long-term support version. These versions continue to see updates over many years. The other versions in-between receive updates only for several months.

JDK & JRE

You said:

but not the JDK. This appears to be what someone who was not a developer would download.

A Java Runtime Environment (JRE) is an implementation of the Java SE specifications, a complete Java platform, with all the software you need to execute an app written in a JVM-compatible programming language such as the Java programming language, Groovy, Scala, and more.

This JRE software consists primarily of a Java virtual machine (JVM) which executes the Java bytecode of a JVM-based app, and adapts that app to the host operating system. A JRE also provides an implementation of the standard Java class libraries. And you get a few tools: jfr, jrunscript, jwebserver, keytool, rmiregistry (docs).

A Java Development Kit (JDK) is a JRE plus tools necessary to write Java apps. These tools include a compiler, a debugger, a profiler, a Javadoc (documentation) processor, and more.

So:

• For you to write a Java app, you need a JDK.
• For your customers to run your app, they need a JRE.

Both JDKs & JREs can be obtained from any of several vendors listed below.

Rolling compatibility

An app compiled for a lower numbered version of Java can be run on the same or higher numbered version of Java. (Unless using a feature later removed, a rare occurrence with Java.)

So yes, an app built for Java 8 can run on Java versions 8, 9, … 17, 18, 19, and 20. But not the other way round. An app built for Java 18 can only be run on Java versions 18, 19, and 20.

JDK vendors

You can obtain a JDK or JRE from any of several vendors.

These vendors include, in no particular order:

• Amazon
• Adoptium (the Eclipse Foundation)
• SAP
• BellSoft
• Microsoft
• Azul Systems
• Oracle
• Red Hat
• IBM

… and more.

If you have no reason to choose a particular vendor, then I suggest starting with Adoptium, a joint effort across the Java community.

Be sure to study the vendor’s legal licensing terms.

Tip: One very convenient way to obtain a JDK/JRE product from a subset of those vendors is by using SDKMAN!, a simple console app.

Every JDK release is production-quality

You said:

JDK 20, which I see has some features in testing

Any feature available by default in Java 20 (or any version) is entirely ready for production use. Each release from any of the JDK vendors has gone through extensive testing.

Any feature not ready for production, because the details may change, is marked as either incubating or preview. These features are never available to you by default. So you cannot use them unwittingly. You have to go out of your way to activate such features. Note that such features are complete in that they have been fully built and tested — they are not “half-baked”. So these features can be used if you so choose, but come with the caveat that they may change or even be withdrawn in the next version.

So understand:

• Every new release of every JDK version is fully ready for production use.
• Java 20 was fully ready for production use.

(Java 20 no longer received updates a few months after the successive version 21 shipped.)

Every JDK is an implementation of Java SE spec

You said:

What is the JDK to Java SE equivalence?

Java SE is a set of specifications published by Oracle Corp.

”Java” (and ”Java SE”) is a trademark owned by Oracle Corp. Available for use only with permission by Oracle.

A JDK is an implementation of the Java specs, plus a compiler and other tools for development and administration.

Some JDK products use the trademark “Java”, but only if permitted by Oracle.

OpenJDK is an open-source project developing a codebase for implementing Java across several chip architectures and operating systems. Many companies and individuals contribute. These include Oracle, IBM, Apple, and others. Many JDK products are based largely, if not entirely, on the OpenJDK codebase.

The term “OpenJDK” may be confusing. Oracle permits any JDK vendor to use the term within the name of their JDK product. Some vendors do, and some do not. Just be clear that the OpenJDK project produces only source code and early-access builds, not finalized binaries or installers . To obtain finalized binaries or installers, choose a vendor from the list seen above.

Java spec number = JDK number

You asked:

What is the JDK to Java SE equivalence?

Every generation of Java specifications use the same numbering as their implementations found in various JDK/JRE products.

So Java 24 specs are implemented by JDK/JRE products numbered 24. Java 25 specs are implemented by JDK/JRE products numbered 25. Sensible and orderly.

More info

For more details, see the whitepaper Java Is Still Free written by pillars of the Java community.