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