Welcome to OpenJDK 8 Updates!
Latest GA release: 8u302
Latest Generally Available (GA) binary releases of the OpenJDK jdk8u project are available at: https://adoptopenjdk.net/upstream.html?variant=openjdk8&ga=ga
Latest Early Access (EA) binary releases of the OpenJDK jdk8u project are available at: https://adoptopenjdk.net/upstream.html?variant=openjdk8&ga=ea
Most recent and past release details:
- 8u302-b08 (GA), July 20th 2021 [Release] [Tag] [Binaries]
- 8u292-b10 (GA), April 20th 2021 [Release] [Tag] [Binaries]
- 8u282-b08 (GA), January 19th 2021 [Release] [Tag] [Binaries]
- 8u275-b01 (GA), November 5th 2020 [Release] [Tag] [Binaries]
- 8u272-b10 (GA), October 20th 2020 [Release] [Tag] [Binaries]
- 8u265-b01 (GA), July 14th 2020 [Release] [Tag] [Binaries]
- 8u262-b10 (GA), July 14th 2020 [Release] [Tag] [Binaries] [Missing changes vs 8u262 of Oracle] (JBS Login required) [Additional changes vs 8u262 of Oracle] (JBS Login required)
- 8u252-b09 (GA), April 14th 2020 [Release] [Tag] [Binaries] [Missing changes vs 8u252 of Oracle] (JBS Login required) [Additional changes vs 8u252 of Oracle] (JBS Login required)
- 8u242-b08 (GA), January 19th 2020 [Release] [Tag] [Binaries] [Missing changes vs 8u242 of Oracle] (JBS Login required) [Additional changes vs 8u242 of Oracle] (JBS Login required)
- 8u212-b03 (GA), April 16th 2019 [Release] [Tag] [Binaries] [Missing changes vs 8u212 of Oracle] (JBS Login required) [Additional changes vs 8u212 of Oracle] (JBS Login required)
- Monday, June 7th 2021: jdk8u-dev forest open (tag: jdk8u312-b00)
- Friday, July 30th 2021: First build promotion jdk8u-dev→jdk8u (tag: jdk8u312-b01)
- Friday, August 6th 2021: Second build promotion jdk8u-dev→ jdk8u (tag: jdk8u312-b02)
- Friday, August 13th 2021: Third build promotion jdk8u-dev→ jdk8u (tag: jdk8u312-b03)
- Friday, August 20th 2021: Fourth build promotion jdk8u-dev→ jdk8u (tag: jdk8u312-b04)
- Friday, August 27th 2021: Fifth build promotion jdk8u-dev→ jdk8u (tag: jdk8u312-b05) & start of Rampdown phase
- Friday, September 3rd 2021: First jdk8u build promotion (tag: jdk8u312-b06)Skipped; no approved critical fixes.
- Friday, September 10th 2021: Second First jdk8u build promotion (tag: jdk8u312-b07b06)
- Friday, September 17th 2021: Third jdk8u build promotion (tag: jdk8u312-b08)Skipped; no approved critical fixes.
- Friday, September 24th 2021: Final jdk8u build promotion & tag before code freeze (tag: jdk8u312-b09b07)
- Tuesday, October 19th 2021: GA; OpenJDK 8u312 released (tag: jdk8u312-ga, likely to be jdk8u312-b10)
- Tuesday, March 2nd 2021: jdk8u-dev forest open (tag: jdk8u302-b00)
- Friday, April 30th 2021: First build promotion jdk8u-dev→jdk8u (tag: jdk8u302-b01)
- Friday, May 7th 2021: Second build promotion jdk8u-dev→ jdk8u (tag: jdk8u302-b02)
- Friday, May 14th 2021: Third build promotion jdk8u-dev→ jdk8u (tag: jdk8u302-b03)
- Friday, May 21st 2021: Fourth build promotion jdk8u-dev→ jdk8u (tag: jdk8u302-b04)
- Friday, May 28th 2021: Fifth build promotion jdk8u-dev→ jdk8u (tag: jdk8u302-b05) & start of Rampdown phase
- Friday, June 4th 2021: Skipped, no critical patches
- Friday, June 11th 2021: First jdk8u build promotion (tag: jdk8u302-b06)
- Friday, June 18th 2021: Skipped, no critical patches
- Friday, June 25th 2021: Final jdk8u build promotion & tag before code freeze (tag: jdk8u302-b07)
- Tuesday, July 20th 2021: GA; OpenJDK 8u302 released (tag: jdk8u302-ga, likely to be jdk8u302-b08)
Older releases can be found in the archive.
OpenJDK 8 updates will be delivered on the same established quarterly cycle used by Oracle i.e. "the Tuesday closest to the 17th day of January, April, July and October."
Development takes place in the jdk8u-dev Mercurial repository and should be the primary place for OpenJDK committers to submit their work.
Code from the development repository is regularly tagged and promoted to the master jdk8u repository, which is used to stabilize and deliver the quarterly releases. Distributors should use this as their primary source for creating OpenJDK builds.
For further process details, you may want to continue reading here.
New fixes should first be submitted to the development repository for the current version of OpenJDK, jdk/jdk, first. The vast majority of changes submitted to the OpenJDK 8 project will be backports from later OpenJDK versions. The version of OpenJDK closest to 8u should be used to minimise the differences between the two JDKs e.g. if 11u is still maintained and has the patch, it should be backported from that repository, rather than jdk/jdk. Occasional exceptions are made when an issue only applies to 8. In particular, the build system can be quite different from that in later versions, especially as regards HotSpot.
Everybody is encouraged to submit fixes for OpenJDK 8 updates by dropping a mail to the jdk8u-dev mailing list. Established community members will help new developers without commit access in getting their patch reviewed. Should you not be willing or not be able to drive a fix into OpenJDK 8 updates, you can still suggest changes. But by only doing that, you are at the grace of the community to pick up your suggestion.
The suggested process is as follows:
- Check the bug database for which JDK versions already have the patch applied.
- When actively starting working on the bug, add a label of the form 'jdk8u-<username>', to the bug - where <username> is your OpenJDK username - to indicate that you are creating a backport.
- Take a copy of the patch from the repository of the JDK version closest to 8u to minimise changes.
- If the patch was developed after the switch to a single repository (during the OpenJDK 10 lifecycle), shuffle the paths using <source jdk>/bin/unshuffle_patch.sh -to9 <original.patch> <9.patch> to get a version that works with the forest of repositories. In some cases, this may mean multiple patches for different repositories.
- If the patch was developed after the switch to the modular system (during the OpenJDK 9 lifecycle) and is not a HotSpot fix, shuffle the paths using <jdk9>/common/bin/unshuffle_patch.sh <repo> <9.patch> <8.patch>. An updated version of this script is maintained in Andrew Hughes' jdk9u-updated branch on github.
- Try to apply the patch by using hg import <patch>. If it applies, go to #8. Otherwise, #7.
- Fix the patch so it applies. This may require identifying other patches which need to backported first, in which case you start this process again with that fix.
- Build the resulting JDK and/or run any new or modified tests, altering if necessary. Again, this may end up needing dependent backports to fix issues that arise.
- You now should have a working patch. If no changes were necessary other than path shuffling, proceed to step #13. Otherwise, step #10.
- Use the webrev tool to create a webrev. Post a mail to email@example.com with the subject "RFR: <bug ID> <bug description>", asking for a review.Explain the motivation and what technical changes were necessary to make the patch work with 8u. Include a link to the bug and to your webrev uploaded on cr.openjdk.java.net. If you can't upload to cr.openjdk.java.net, ask someone with OpenJDK authorship status or above to do it on your behalf.
- Update the bug with a link to the RFR on the mailing list and add the label 'jdk8u-needs-review'.
- Wait for a successful review from an OpenJDK 8u reviewer.
- Go to the bug in JIRA and replace the 'jdk8u-needs-review' label with the 'jdk8u-fix-request' label. Write a comment preceded with "Fix Request [8u]". Explain the motivation for the fix, and either explain that it applies cleanly to 8u with patch shuffling, or link to the successful review thread on the mailing list. If you don't have bug database access, someone will need to do this on your behalf. In the case that the bug is inaccessible (the page displays "You can't view this issue"), please make the request by e-mail to firstname.lastname@example.org with the subject "RFA: <bug ID> <bug description>" and the same motivation in the body of the e-mail as would have been included in the request comment. It may also be worth replying to the original review thread, asking for the bug to be made public.
- Wait for an 8u maintainer to add jdk8u-fix-yes to the bug.
- The change can now be committed & pushed to the appropriate jdk8u-dev repository. If you don't have committer or above status, someone will need to to do so on your behalf. Patches that apply cleanly or only need a few minor changes which don't alter the code (e.g. copyright header fixes, same changes in a different context) should use the original author & reviewers for the commit. If the fix was reviewed, those reviewers should be appended to the end of the list. If substantial code changes were needed to create the 8u fix, authorship should go to the backporter and reviewers should only list those who reviewed the altered patch.
- Pat yourself on the back, having successfully got a patch into OpenJDK 8u.
Backport bugs will be automatically created on push by the hgupdater system. If a backport bug needs to be explictly created - for example, for a Compatibility and Specification Review (CSR) - then please apply labels to that bug to avoid the need to work on two different bugs for the one issue. The fix version should be set to 'openjdk8ux' where x is the current version of 8u being developed. Please avoid using 'openjdk8u' as the hgupdater will not resolve such bugs automatically. Maintainers should double-check this fix version is correct when approving.
In general, we follow the common rules for the jdk-updates project.
If the backport does not apply to the 8u tree via the automated shuffling described above, it should first be submitted for review.
Push approval for a fix is then requested by setting the jdk8u-fix-request label on the original JBS bug. The maintainer will either approve this by setting jdk8u-fix-yes or reject it by setting jdk8u-fix-no. Outstanding approvals can be monitored here. If, and only if, the fix is approved, it may be pushed to the appropriate jdk8u-dev repositories. Approved fixes show up in this JBS filter (login required).
During the later stages of a release cycle, the release enters rampdown. The master jdk8u repositories contain the latest version of that release, while the jdk8u-dev repositories are used to start work on the next release. If a change needs to be pushed to a release in rampdown, push approval can still be requested using the jdk8u-critical-request label. As the name of this tag suggests, this process is intended for fixes such as major regressions that must make the release. More minor bugs and new features should go in the next release being developed in jdk8u-dev. The maintainers may approve with jdk8u-critical-yes, defer to jdk8u-dev or reject altogether. Outstanding approvals for critical fixes can be monitored here. If, and only if, the fix gets approved with jdk8u-critical-yes, it may be pushed to the jdk8u repository. Approved critical fixes show up in this JBS filter (login required).
At the end of the month prior to the release month, the jdk8u repository is declared frozen, so embargoed security fixes can be added in private during the final few weeks. On release day, the final version will be pushed to the jdk8u repository and source bundles made available.
Some filters will only work for users that are logged into JBS.
Backports Needing Review
Standard Fix Requests
Critical Fix Requests
Filters for Release 8u302
Filters for Release 8u292
Filters for Release 8u282
Filters for Release 8u272
The jdk8u-dev forest for ongoing development can be cloned using this command:
hg clone jdk8u-dev;sh get_source.sh
The corresponding master forest jdk8u can be cloned using this command: hg clone
Recent space activity