Corretto 8: a still-shipping OpenJDK 8 build with a deliberately serial build

.NOTPARALLEL is the first rule, and that is the whole story

The most surprising thing in the Corretto 8 repository is three lines into the top-level Makefile, above any target, and it is a build-wide constraint rather than a default.

# This must be the first rule
default:

# Inclusion of this pseudo-target will cause make to execute this file
# serially, regardless of -j.  Recursively called makefiles will not be
# affected, however. This is required for correct dependency management.
.NOTPARALLEL:

The comment states the reason as correct dependency management. Whatever the historical justification, the effect for anyone building this today is that passing -j to the top-level make buys you nothing, and the serial execution applies to this makefile rather than to the ones it recurses into. If you have a build farm and a plan to parallelise, the top-level entry point is where that plan meets a wall.

This is the sort of detail that tells you what a fork actually is. Corretto 8 is not a re-architecting of OpenJDK; it is a distribution channel that inherits the build system it inherited. The repository layout says the same thing: common/, hotspot/, jdk/, langtools/, nashorn/, corba/, jaxp/, jaxws/, make/, installers/ and test/ are the standard OpenJDK 8 source tree, with build.gradle, gradle.properties, settings.gradle and gradlew sitting alongside the Makefile, configure script and make/ directory.

For an adopter this is good news in one specific sense. The build system is the one your existing JDK 8 build tooling already knows how to drive, including whatever wrapper, container or CI image you standardised on years ago. It is not a modernised toolchain, and that is a feature when the goal is producing a byte-identical runtime on a new base image.

GNU make is enforced by the Makefile, not by a README note

The second build-file fact catches out almost everyone building this on a Mac, and the enforcement is in the file rather than in the documentation.

TEST_FOR_NON_GNUMAKE:sh=echo You are not using GNU make/gmake, this is a requirement. Check your path. 1>&2 && exit 1

Above that line, a comment explains why the shell code is conditional: it will be executed on /usr/ccs/bin/make on Solaris, but not in GNU make. The effect on macOS is direct. The system make on a Mac is BSD make, and it does not implement the constructs the OpenJDK build uses, so the build stops immediately with a message telling you to check your path. The fix is gmake.

What makes this worth writing down is that the README does not mention it. The README's build guidance is a link to the OpenJDK building instructions at openjdk.java.net, plus the two local copies at doc/building.html and doc/building.md. Everything specific to building this particular tree, including the gmake requirement and the serial execution, is discoverable only by opening the Makefile. That is a normal pattern for a fork that wants to stay close to upstream, and it does mean a first build is a read-the-Makefile exercise rather than a follow-the-README one.

The local copies matter for a different reason. Pointing at openjdk.java.net means pointing at documentation for current OpenJDK, which describes a build system that has since changed shape. doc/building.html and doc/building.md in this repository are the instructions that matched this tree at the time they were written, so if the online page describes steps this Makefile does not have, the local file is the one that agrees with the code in front of you.

Two build systems in one root, and no guidance on which to use

The repository root contains a Makefile, a configure script and a make/ directory, and next to them build.gradle, settings.gradle, gradle.properties and gradlew with a gradlew.bat for Windows. There is also a .gradle/ directory and a .jcheck/ directory.

Two build systems coexisting at the root of a JDK source tree is unusual, and the README does not explain the division of labour. Nothing in the documentation says whether the Gradle files are used for a subset of the tree, whether they are a newer path being brought up alongside the older one, or whether one is on the way out. A contributor reading the repository listing has to work this out from the files themselves.

The practical question for someone who only wants a runtime is easier than the question for someone who wants to contribute. Nobody building Corretto 8 needs to understand either build system to consume it. The tagged release archives are on the GitHub releases page and on downloads.corretto.aws, filtered by build and version, and a production deployment consumes the artifact rather than the repository. The Makefile and the Gradle files only matter if your intent is to produce your own build.

That is the right mental model for this project, and it is worth stating because the repository is easy to misread. Corretto 8 is a source distribution, not a package you build by default. Its consumers are deployment pipelines pointing at a download, its contributors are the people who cut the tagged builds, and the two activities share a repository without being the same activity.

amazon-cacerts sits in the source tree as a tracked file

One entry in the top-level listing is not standard OpenJDK, and it has direct security consequences: amazon-cacerts.

It is a tracked file, not a build output, which means the certificate bundle that Corretto 8 trusts is a source artifact you can read, diff and review. That is better than the alternative, and it is also the reason to look at it. A JDK's trust store decides which TLS peer certificates your service will accept, and in this distribution that decision comes from a file Amazon ships and maintains rather than from the operating system or from upstream OpenJDK. When a certificate authority is added or removed, the change lands here, in a repository, in a commit you can see.

For a service running on Corretto 8 in production, the practical consequence is that trust configuration is part of your dependency review surface. If your organisation pins or filters certificate authorities at the OS level, or injects a corporate root into the JVM through your own trust store, Corretto's bundle is the layer you are overriding rather than the layer you are inheriting. The README does not discuss trust store configuration at all, so this is not something the documentation will walk you through; it is something you decide deliberately.

The other file in that category is THIRD_PARTY_README, which the Licenses and Trademarks section tells you to read alongside LICENSE, ASSEMBLY_EXCEPTION and TRADEMARKS.md. Four files, four different things. THIRD_PARTY_README covers bundled third-party components, which for a JDK means the native libraries and bundled toolchains that ship inside the runtime. If your compliance process asks what is inside a JDK build, that file is where the answer starts, and for a distribution whose selling point is that it is production-ready, it is the file to read before the marketing claim.

It is also a maintenance obligation rather than a one-off check. Every release that changes a bundled component changes that file, and the point-in-time snapshot you read today is not the snapshot in the next build.

8.504.01.1 is three counters, not one

Corretto 8 version numbers are worth decoding once, because the repository documents the scheme in a way that makes a release name self-explanatory.

The source code for each release is recorded by a branch or a tag named release-8.XXX.YY.Z, where XXX is the OpenJDK 8 update number, YY is the OpenJDK 8 build number, and Z is the Corretto-specific revision number. Z starts at 1 and is incremented in subsequent releases as long as the update and build number stay constant.

That last clause is the useful part. A Corretto release that changes nothing about the underlying OpenJDK build is not a new upstream release, it is a bump of the trailing digit. So the three most recent tags decode differently from each other:

8.492.09.2, tagged 2026-05-07, is OpenJDK update 492, build 09, Corretto revision 2. The revision is 2 rather than 1, which under the documented rule means Amazon shipped this OpenJDK build twice for its own reasons.

8.502.07.1, tagged 2026-07-22, is update 502, build 07, Corretto revision 1. This one is a first pass at a new upstream build.

8.504.01.1, tagged 2026-08-18, is update 504, build 01, Corretto revision 1. The build number has reset to 01, which is what an upstream update bump looks like.

For a team pinning a runtime, this is the difference between a security upgrade and a repackaging. Moving from 8.502.07.1 to 8.504.01.1 moves you two upstream update numbers and brings whatever the JDK 8 project changed in between. Moving within a fixed update and build number and watching Z increment is a Corretto-side change only. If you run a change-management process, this is the field that tells you whether to expect a behavioural difference, and version.txt at the repository root is where the build reads it from.

develop, master, and two branches frozen in 2018 and 2019

The README documents the branch model in four short paragraphs, and it is worth reading because the default branch is develop, not master.

develop is the default branch. It absorbs active development contributions from forks or topic branches via pull requests that pass smoke testing and are accepted. master is the stable branch, the starting point for the release process, absorbing contributions from the develop branch that pass more thorough testing and are selected for releasing. The distinction is the testing bar, not the intent: smoke testing gates what lands on develop, more thorough testing gates what moves to master.

The other two branches are historical snapshots with fixed dates. ga-release is the source code of the GA release on 01/31/2019, and preview-release is the source code of the preview release on 11/14/2018. These are the general-availability and preview points of the original Corretto 8 launch, kept as branches so anyone can diff against the state of the tree as it shipped rather than as it evolved. That is a thoughtful thing to keep and it is not common.

What the model does not tell you is where an arbitrary tagged release sits in the branch graph, beyond the release-8.XXX.YY.Z naming convention. If you are building from source, the safe target is a release tag, not develop. Building develop gives you everything that passed smoke testing, which by the project's own definition has not yet passed the testing that qualifies it for release.

The cadence the branches imply is quarterly to twice-yearly. Three tagged builds in 2026 so far, in May, July and August, with the last push on 2026-09-28. For a distribution of a Java version whose feature set is frozen and whose remaining work is security and platform maintenance, that is a plausible rate: you are not waiting for language features, only for upstream fixes and for the base operating systems to keep building on.

GPL-2.0, two exception files, and a Makefile header from 2012

The licence situation is four files, and reading them in the wrong order will mislead you.

The repository is GPL-2.0, and the top-level entries confirm all four documents the Licenses and Trademarks section points at: LICENSE, THIRD_PARTY_README, ASSEMBLY_EXCEPTION and TRADEMARKS.md. The clearest statement of the arrangement is not in any of them but in the header of the Makefile itself, which is the standard Oracle GPL-2.0-with-Classpath-exception boilerplate: the code is free software under GPL version 2 only, as published by the Free Software Foundation, and Oracle designates the file as subject to the Classpath exception provided by Oracle in the LICENSE file.

So there are two exception documents, not one. The Classpath exception is the standard OpenJDK arrangement that lets you link your own code against the class library without the whole combined work becoming GPL. ASSEMBLY_EXCEPTION is separate and covers assembling the distribution. TRADEMARKS.md covers the marks, which matters for a vendor distribution: the GPL covers the code, and the code being redistributable does not make the name redistributable in every context.

What is more interesting is the provenance visible in that header. It is dated 2012 and 2013, attributed to Oracle and its affiliates, carries Oracle's Redwood Shores address and directs questions to Oracle's legal entity. In a repository whose last push was 2026-09-28, an Oracle address in a 2012 copyright header is not an error. It is the record of what the upstream code was, and the Classpath exception depends on that record being intact. Forking a GPL project means preserving the notices, and the visible result is that Amazon's build carries Oracle's copyright statements on the files it inherited and its own on the files it wrote.

The module list is the last thing to look at. nashorn/, corba/, jaxp/ and jaxws/ are present as directories, and they are the parts of the JDK that later versions deprecated and removed. Their presence in an 8-only tree is not a maintenance burden to be cleaned up; it is the reason this fork exists as a separate repository, and any migration plan that assumes the JDK 8 module set looks like a current JDK will be wrong.

Editorial conclusion

Adopt Corretto 8 if you have a service on Java 8 and want a vendor that is still cutting builds, because the release history shows tagged updates in May, July and August 2026 and a push on 2026-09-28, which is a different position from a project that quietly stopped. Do not adopt it as a base for anything new, and do not adopt it if a serial build is a blocker, because .NOTPARALLEL is the first rule in the top-level Makefile and that is not going to change while the branch tracks OpenJDK 8. Verify four things. Confirm the version numbering you are pinning against the four supported branches, develop, master and the two frozen release branches, so you are building a tag rather than the default branch. Run gmake rather than make, because the Makefile exits with an explicit message on anything but GNU make. Decide whether the shipped amazon-cacerts trust bundle is acceptable in your environment, since it is a tracked source file that determines what your TLS peer certificates are checked against. And read TRADEMARKS.md alongside the GPL-2.0 and the two exception files rather than assuming the licence is a single document. The deciding fact is that Corretto 8 is a maintenance distribution, not a development one, and the right question is how many years of Java 8 you still have to run.

Frequently asked questions

Official sources

1. corretto/corretto-8 on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases