JDK: a mirror of Java source trees for versions 1.6 through 21

One directory per JDK release, with the update numbers in the name

The repository is a plain collection of source trees rather than a tool. The top-level entries show one directory per release, named with the version and, where useful, the exact build: JDK1.6-Java SE Development Kit 6u45, JDK1.7-Java SE Development Kit 7u80, JDK1.7, JDK1.8, JDK1.9, JDK10-Java SE Development Kit 10, jdk-11.0.2, jdk-12, jdk-13, jdk-14, jdk-14-GA, JDK-15, JDK-16, jdk-17, JDK-18-ea31, JDK-18.0.2.1 and jdk-21. There is also a JDK_demos_8u66 directory for the official Java demos, and the README says the tree includes the official demos. The layout is intentionally literal, which makes it easy to find a specific release but means the naming is inconsistent. Some directories carry the marketing name of the build, some carry the artifact-style name, and the 1.7 and 1.8 directories are ambiguous because they appear to be the plain version folders rather than the update-specific ones. The practical instruction the README gives is that the code differs slightly between versions and even between update builds of the same version, giving the example of Java SE Development Kit 7u1 against Java SE Development Kit 7u80. So a directory named for a version is not a guarantee of a specific build, and you should check what is actually inside before citing it.

The rt_debug jar exists to make variable values visible when you debug

The single most useful thing here is not the source but the repackaging. The README describes the JDK sources being repackaged so that debugging JDK source shows the values of variables, and it links two such archives, rt_debug_1.7.jar and rt_debug_1.8.jar, hosted on a download portal. This solves a specific and well-known problem. By default, when you attach a debugger to code in the JDK runtime, the source is available but the local variable values are not, because the standard runtime jars are compiled without the debug information for those variables, or with it stripped in a way that the debugger cannot use. A repackaged runtime that keeps the local variable tables gives the debugger something to show. The cost is that this is a modified copy of a proprietary runtime, and the two linked archives are hosted on a third-party download site rather than released through the repository itself. The README also points to a separate repository, JDK-Study, described as a place for accumulating daily notes on JDK source code and the fundamentals, which is where the author's own study notes live. The repository itself publishes no GitHub releases, so there is no tagged version of these jars to pin, and the last push was on 2026-06-15, which is also the date the README records for adding JDK 21 GA.

The version list runs to JDK 21 and records the date each tree was added

The README works as a changelog of what was added and when. It notes JDK 1.9 with the modular system, JShell and collection factory methods on 2017-10-07, then JDK 1.7 with the last and newest 1.7 release, Java SE Development Kit 7u80, and JDK 1.6 with the last 1.6 release, 6u45, both dated 2018-03-11. JDK 10, the first release of that version, followed on 2018-03-24. The pattern then moves to point releases and download links: JDK 11.0.2 on 2019-03-25, JDK 12 on 2019-03-25, JDK 13 on 2019-09-28, JDK 14 on 2019-11-24, JDK 14 GA on 2020-03-29, JDK 15 on 2021-12-19, JDK 16 on 2021-12-26, JDK 17 on 2021-12-13, JDK 18 build 31 on 2022-01-16, JDK 18.0.2.1 GA on 2022-09-04, and JDK 21 GA on 2026-06-15. Each entry also points at where the official distribution was downloaded from, mostly jdk.java.net for the open builds and Oracle's download pages for JDK 11 and 12. That combination of a date and an upstream URL per entry is what makes the tree usable as a research reference. You can tell which upstream artifact a given directory corresponds to and where to fetch the matching binary, which matters when you are comparing behaviour between releases rather than just reading code.

The JDK 14 JEP list gives the repo a second, narrower purpose

Buried in the README is a summary of the JDK 14 feature set, and it is a different kind of content from the source trees. Two groups are listed. The first are JEPs proposed to target JDK 14 whose review ended, each with a number, a title and a date of 2019/11/25 or 2019/12/02: number 305, Pattern Matching for instanceof as a preview, 343, a Packaging Tool as an incubator feature, 359, Records as a preview, 366, deprecating the ParallelScavenge and SerialOld garbage collector combination, 368, Text Blocks as a second preview, and 365, ZGC on Windows, dated 2019/12/02. The second group are JEPs targeted to JDK 14, listed by number and title without dates: 345, NUMA-aware memory allocation for G1, 349, JFR event streaming, 352, non-volatile mapped byte buffers, 358, helpful NullPointerExceptions, 361, switch expressions as a standard feature, 363, removal of the Concurrent Mark Sweep garbage collector, 364, ZGC on macOS, and 367, removal of the Pack200 tools and API. Read this list as a table of contents for a version rather than as marketing. The preview entries in particular are the ones that tell you which features were still incubating in that release, which is exactly the detail a reader comparing 14 with 15 or 16 needs.

No install path, because there is nothing to install

There is no build, no package manager entry and no container recipe here, and that is the correct shape for the project. The README gives no installation steps, and it does not need to, because what it distributes is source code. The closest thing to a getting-started path is the list of upstream download URLs recorded next to each version entry, which is where you get an actual JDK to compare against the sources, and the two rt_debug jar links for the case where you want to debug the runtime itself. If you want to read the source in an editor, the useful trick that follows from the directory naming is to point your IDE at the tree for the version you care about, or better, install the matching JDK and use the src.zip it already ships with, since the repository is a convenience mirror of exactly that content. The repository's own purpose statement is that it is for learning, and it also links a separate study repository for accumulated notes. There is no package.json, no pom.xml, no build.gradle and no Makefile in the top-level listing, which confirms there is nothing to compile.

The licence question is the real caveat for a mirror of proprietary source

The repository is recorded under the Apache-2.0 licence and ships a LICENSE file, but the contents are the Java platform source, which is Oracle's code under Oracle's own terms. Those two things are not the same thing, and the repository documentation does not attempt to reconcile them. The README links the OpenJDK download pages and the Oracle download pages as the sources the trees came from, which is the honest framing: this is a copy of code Oracle distributes under the Java SE terms, mirrored in a repository with a different licence header. For personal study and reading, which is the stated purpose, this is a common and mostly uncontroversial practice. For anything else, in particular for including these files in a product, a training course you sell, or a derived work you redistribute, you need to look at the Oracle licence terms for the specific release rather than the repository's licence file, and that is a legal question this project cannot answer. The safe reading is that the repository is a study aid, and the moment its contents leave that purpose the licence reasoning changes. Nothing in the README addresses redistribution, rollback of a mistaken commit, or how the tree is kept in step with upstream, so treat the recorded dates as the best available provenance rather than a guarantee.

Where this sits against building a JDK yourself

The realistic alternative for reading JDK internals is the one Oracle and the OpenJDK project already provide. Every JDK download ships a src.zip with the platform sources, so if you need the code for the exact build you are running, the archive inside your own installation is a better match than any mirror, and it is guaranteed consistent with the binary you are debugging. The open JDK 21 build, which is what the most recent entry in this repository points at, is distributed with sources in the same way, and the upstream project publishes its own source tree. So the difference in approach is not that this repository shows you something the official distribution hides. It is that here you can hold many versions side by side without installing many JDKs, and that the rt_debug jars exist to make local variable values visible when you step into runtime code. What it does not give you is a buildable toolchain, a way to rebuild the runtime, or a compatibility promise, and it is a mirror rather than a fork, so anything it missed at the time of copying stays missed until the next push.

Editorial conclusion

The JDK repository suits a developer who wants to read how a particular JDK release implemented a class, compare the same class across versions, or step through the runtime with variable values visible. It is the wrong tool if you need a buildable Java distribution, because it holds sources and repackaged runtime jars rather than a compiled toolchain, and it is the wrong tool if you need a licence review of the code, since the sources are Oracle's under their own terms while the repository carries Apache-2.0. Verify first which JDK versions are actually present in the tree you clone, since the listing is not uniform, and read the per-version notes before assuming two directories with the same version number contain identical code.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. zxiaofan/JDK on GitHub