WARNING: These artifacts are not well-tested, not virus-checked, may contain horrible bugs that could lead to data corruption, engulfing machines in flames, sharing your financial data, selling your pets on eBay, etc. etc. etc. everything that applies for binaries^W code^W anything downloaded from the Internet. Be cautious. If in doubt, build from the source yourself, and/or run on staging environment that is not painful to restore.

Our motto: "builds.shipilev.net — still more secure than npm install"

openjdk-* builds are usually from the latest revisions of their corresponding repositories, to capture the latest changes in projects. Many builds trigger on commit, some trigger nightly, every build triggers at least weekly. Some builds are verified with internal tests, but most are published as is.

Some of these builds are wrapped in Docker containers, try docker pull shipilev/openjdk[:tag]. Please see the DockerHub pages for the list of available tags.

The binary flavors are:

{Linux, Windows}: different OS targets; unfortunately, no Mac builds are here, because I cannot build them easily: it seems MacOS X cannot be virtualized on non-Apple hardware.

{aarch64, arm32-hflt, mipsel, mips64el, ppc64le, s390x, x86_32, x86_64}: different target architectures. All platforms except x86_64 are cross-compiled.

{server, zero}: different VM flavors. The normal JDK is Server: enables all JIT compilers, all GCs, etc. The very basic JDK is Zero VM: it has only one C++-based interpreter, and handful of GCs, etc. Most platforms have Server VM builds. Some platforms do not have JIT compilers implemented, and thus have only Zero VMs. For easier testing, all architectures build Zero VMs, even when Server VMs are available.

{release, fastdebug, slowdebug, optimized}: different optimization levels. The normal JDK is "release": it is the fastest one. "optimized" builds are like "release", but also able to print more JIT diagnostics, useful when working on optimizing compilers. If unsure, use "release". "fastdebug" builds enable internal asserts and verifications, and thus run significantly slower, but are able to diagnose much more VM bugs; but they are still reasonably fast. "slowdebug" builds run with lowest level of native optimization, making them a perfect vehicle to work with native debuggers.

{gcc*-glibc*, msvc*}: compiler/library toolchains used to compile the builds. This affects compatibility, as systems with older libcs/kernels would not be able to run binaries compiled for newer libc. Compiling for older libc is done by compiling in the older OS distributions, which implies older compilers too. For the best compatibility (for example, sharing the build across the heterogenous hosts with unknown libc versions), select the build with lower libc version. For the best performance and when you know the minimum libc version across the hosts (for example, deploying in the Docker container), select the build with higher libc version. The build with incompatible libc version would usually fail to start.

patch-* contain the webrevs against upstream jdk for many projects. these are great to look around the changes done in project, for curiosity, debugging, and general review.