JDK Releases (original) (raw)
The naming, versioning and types of Java releases has changed a number of times; the information on this page is not a complete history and details may be missing from the very early releases.
Java Release Types
Different types of Java releases are made available, some of them include new enhancements and can be adopted over time, whereas some contain vulnerability fixes and should be adopted as quickly as possible. Some release types have changed in line with the versioning and release model changes, and are no longer produced.
| Type | Description |
|---|---|
| Major/Feature Release | Releases where the Specification of the Java SE Platform (see below) can be changed: APIs can be added, deprecated or removed. With the release of JDK 10 the release model was updated to be date driven (every six months) vs. content driven. The Major releases were renamed to Feature Releases to reflect that change. |
| Minor Release | Release with a large number of fixes or introduces new functionality, port or OS upgrade. |
| Update Release | Focused on bug fixes and platform/3rd party updates and until the introduction of CPU releases also contained vulnerability fixes. |
| Patch Release | Contains critical bug fixes, but no additional security vulnerability fixes (unless it is delivered as part of a Security Alert (see below)). |
| CPU/Security Release | Until around 2008 vulnerabilities were fixed as they were ready in each release family and there was not the concept of a Security release apart from a few releases that were for a specific security fix. By 2008 vulnerabilities started to be fixed in a coordinated fashion across all applicable release families, three times a year. |
| PSU Release | Patch Set Update (PSU) releases were released on the same day as a CPU and contained additional functional fixes as well as the vulnerability fixes, when there was a corresponding PSU then the CPU would not contain general bug fixes. |
| ER/SA | Unscheduled releases for vulnerability (Security Alert - SA) or non-vulnerability (Emergency Release - ER) fixes. |
| Performance Release | Releases (ending in p) focused on performance improvements and usually contained an updated version of HotSpot which was shipped with new performance benchmark results. |
Java Release Dates
In 2013 the Java Security release model changed to be in line with the Oracle Critical Patch Update (CPU) schedule where CPU releases are released on the third Tuesday of January, April, July and October. Prior to April 2022 the rule was Tuesday closest to the 17th of those months. Full details can be found here, along with instructions on how to subscribe to CPU Alert notifications. Feature releases are scheduled for release in the middle of March and September. The exact dates are posted several months in advance on https://openjdk.java.net/projects/jdk.
Java Release Support Timeline
The length of time updates are provided for a Feature release is outlined in the Oracle Java SE Support Roadmap. Long Term Support (LTS) releases are indicated in the follow table with "LTS".
| Release Family | GA | End Of Support Life (EOSL) |
|---|---|---|
| 25 LTS | 16th September 2025 | September 2033 |
| 24 | 18th March 2025 | September 2025 |
| 23 | 17th September 2024 | March 2025 |
| 22 | 19th March 2024 | September 2024 |
| 21 LTS | 19th September 2023 | September 2031 |
| 20 | 21st March 2023 | September 2023 |
| 19 | 20th September 2022 | March 2023 |
| 18 | 22nd March 2022 | September 2022 |
| 17 LTS | 14th September 2021 | September 2029 |
| 16 | 16th March 2021 | September 2021 |
| 15 | 15th September 2020 | March 2021 |
| 14 | 17th March 2020 | September 2020 |
| 13 | 17th September 2019 | March 2020 |
| 12 | 19th March 2019 | September 2019 |
| 11 LTS | 25th September 2018 | September 2026 |
| 10 | 20th March 2018 | September 2018 |
| 9 | 21st September 2017 | March 2018 |
| 8 LTS | 18th March 2014 | December 2030 |
| 7 LTS | 11th July 2011 | July 2022 |
| 6 LTS | 12th December 2006 | December 2018 |
| 5 LTS | 30th September 2004 | July 2015 |
| 4 LTS | 13th February 2002 | March 2013 |
| 3 LTS | 8th May 2000 | April 2011 |
| 2 LTS | 4th December 1998 | December 2003 |
| 1.1 LTS | 28th March 1997 | January 2003 |
| 1.0 LTS | 23rd January 1996 | October 2002 |
Java Release Naming and Numbering
When first released Java was named Java Development Kit and abbreviated as JDK. With the release of Java version 2 there was a rebranding to Java 2 - full name: Java 2 Software Development Kit, abbreviated to Java 2 SDK or J2SDK. With the release of JDK 6 we went back to using JDK without the “2”.
The Java version-string format has changed several times throughout the years. The following table outlines the main changes.
| Release Families | Numbering |
|---|---|
| 10 and above | JEP 322 refined the version numbering further to match the now time based release model. |
| 9 | With JDK 9 there was an effort to redesign the by now complex numbering from scratch as part of JEP 223. |
| 6, 7, 8 | With JDK 6 Minor numbers were dropped from the Product Version. During this period the update numbering went through various iterations moving from incrementing by 1, then 2, followed by increments of 5 and finally 10 - it also became standard for the CPUs to have odd version numbers, and updates even. |
| 5.0 | JDK 5.0 dropped the leading 1(Major) from the Product Version but was kept in the Developer Version number. The Minor number was kept but no Minor releases were ever shipped, 5.1 (Dragonfly) was planned but never released. |
| 1.2.0, 1.3.0, 1.4.0 | While 1.2 was a remarkable release from the perspective of the amount of change, it had the version 1.2 vs. 2.0, and it was clear that there would never be another "Major Release". Consequently, Minor releases (1.2, 1.3 etc.) were referred to as Major releases, and Micro releases (1.3.1, 1.4.2) as Minor releases. Retrospectively, 1.1 is also referred to as a Major Release, though 1.1.1, 1.1.2 etc. continue to be Micro Releases. |
| 1.1 | 1.1 updates ended in _002, _003 etc. for Windows and Solaris Reference releases and _02, _03 for Solaris Production releases. |
| 1.0 | The numbering started off with the model Major.Minor.Micro. |
Code Names
Code names were used for early Java releases; the Major releases were named after birds or mammals, while the minor releases were named after insects (given they were bug-fix releases). Hopper was short for grasshopper and ladybird is the British name used for a ladybug. The 1.2 release was called "Playground" by some, but that was never an official or broadly-used code name. The practice of naming releases ended with JDK 7.
| Version | Code Name |
|---|---|
| 7 | Dolphin |
| 6 | Mustang |
| 5.0 | Tiger |
| 1.4.2 | Mantis |
| 1.4.1 | Hopper |
| 1.4.0 | Merlin |
| 1.3.1 | Ladybird |
| 1.3.0_01 | Firefly |
| 1.3.0 | Kestrel |
| 1.2.2 | Cricket |
| 1.2.1 | Gnat |
| 1.1.8 | Chelsea |
| 1.1.7 | Brutus |
| 1.1.6 | Abigail |
| 1.1.5 | Pumpkin |
| 1.1.4 | Sparkler |
Java SE Platform
The Java Community Process (JCP) standardizes and ratifies the Java SE Platform via a Java Specification Request (JSR). Every JSR consists of three components: a Specification, a Reference Implementation (RI), and a Technology Compatibility Toolkit (TCK). The purpose of the RI is to prove that the Specification may be implemented, and the TCK is a test suite used to verify that the implementation is compliant with the Specification.
For the JSR which standardizes the Java SE Platform, the Platform JSR Specification consists of the Java SE API Specification, the Java Language Specification (JLS), the Java Virtual Machine Specification (JVMS), and further narrative specifications such as the JNI Specification, the JAR File Specification, and the Serialization Specification. Each Feature (previously "Major") Release of the JDK is the RI for the corresponding Platform JSR and finally, the Java Compatibility Kit (JCK) is the TCK for the Java SE Platform.
In addition to the Specification of the Java SE Platform, the JDK is further specified by a number of other documents including the Tool Specifications (more commonly referred to as the "man" pages), the JDK API Specifications (see the 'JDK' tab in the javadoc), and the Standard Doclet Specification.
The typical update release does not make any changes to the Specification of the Java SE Platform. However, in exceptional circumstances when a specification change is needed, a Maintenance Release (MR) of the Platform JSR is required - the following table lists every MR of the Java SE Platform JSRs:
| Family | Date | JSR | RI | Specification (1) | Implemented by (2) | Reason |
|---|---|---|---|---|---|---|
| Java SE 17 | ||||||
| 2024-07-02 | JSR 392 MR 1 | 17.0.0.1 | 17.1 | 17.0.12 | Relax the java.awt.Robot specification,backport JEP 452 Key Encapsulation Mechanism API,and add system property for Java SE specification maintenance version | |
| Java SE 11 | ||||||
| 2024-07-02 | JSR 384 MR 3 | 11.0.0.2 | 11.3 | 11.0.24 | Relax the java.awt.Robot Spec | |
| 2023-05-09 | JSR 384 MR 2 | 11.0.0.1 | 11.2 | 11.0.20 | New code points for GB 18030-2022 | |
| 2019-03-26 | JSR 384 MR 1 | 11 | 11.1 | 11.0.3 | New Japanese Era, Currency Changes,and Standard Cryptographic Algorithm Names | |
| 2018-09-19 | JSR 384 | 11 | 11 | |||
| Java SE 8 | ||||||
| 2024-07-02 | JSR 337 MR 6 | 8u44 | 8.6 | 8u411 | Relax the java.awt.Robot specification | |
| 2023-05-09 | JSR 337 MR 5 | 8u43 | 8.5 | 8u381 | New code points for GB 18030-2022 | |
| 2022-07-26 | JSR 337 MR 4 | 8u42 | 8.4 | 8u351 | java.lang.ref.Reference object updates | |
| 2020-02-05 | JSR 337 MR 3 | 8u41 | 8.3 | 8u251 | ALPN, RSASSA-PSS (for TLS 1.3) | |
| 2019-03-26 | JSR 337 MR 2 | 8u40 | 8.2 | 8u211 | New Japanese Era, Currency Changes,and Standard Cryptographic Algorithm Names | |
| 2015-03-03 | JSR 337 MR 1 | 8u40 | 8.1 | 8u40 | Verifier update in JVMS | |
| 2014-03-04 | JSR 337 | 8 | 8 | |||
| Java SE 7 | ||||||
| 2015-03-12 | JSR 336 MR 1 | 7u75 | 7u75 | Verifier update in JVMS | ||
| 2011-07-20 | JSR 336 | 7 | 7 | |||
| Java SE 6 | ||||||
| 2015-03-18 | JSR 270 MR 1 | 6u91 | 6u91 | Verifier update in JVMS | ||
| 2006-12-11 | JSR 270 | 6 | 6 |
(1) Programmatic access to the maintenance specification version was originally added to JDK 19 and backported to JDK 8 with JSR 337 MR 4, JDK 11 with JSR 384 MR 2 and JDK 17 with JSR 392 MR 1.
(2) The JCP requires that each Maintenance Release includes an RI, although that RI should not be used in production. Instead, the update release of the JDK which corresponds to ('implements') the MR should be used in production. For example, JDK 8u381 should be used instead of JDK 8u43
The JCP was created in December 1998. Prior to Java SE 8, all significant new features were developed by independent JSRs under the JCP then incorporated by reference in the Platform JSR. Starting with Java SE 8, this practice was discontinued, and the JDK Enhancement Proposal (JEP) Process was introduced. When a JEP of "Scope = 'SE'" is targeted to a specific release, it is linked in the Platform JSR.
Additional Information
- In 2010 Oracle acquired Sun Microsystems Inc., releases after mid 2010 were re-branded from Sun to Oracle.
- Prior to Java 11 in 2018, a Java release included both a JRE and a JDK, whereas in Java 11 and later, a Java release consists solely of the JDK.
- Updates to the supported Crypto algorithms are tracked in the JDK Crypto Roadmap.
- The mapping of TZ data to release is available in the Timezone Data Mapping page.