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.

These binaries carry multiple JVMs: {release, fastdebug, slowdebug}: built with different optimization levels. The normal JDK is with "release" VM: it is the fastest one, and it is default. "fastdebug" VM enables internal asserts and verifications, and thus run significantly slower, but is able to diagnose much more VM bugs; it is still reasonably fast. Use java -fastdebug to run a fastdebug VM, or switch-to-fastdebug.sh to switch to fastdebug by default. "slowdebug" VM runs with lowest level of native optimization, making it a perfect vehicle to work with native debuggers, or get the crash dumps unaffected by inlining. Use java -slowdebug to run a slowdebug VM, or switch-to-slowdebug.sh to switch to slowdebug by default.

These binaries are cross-compiled with modern compilers, but lower glibc: This affects compatibility, as systems with older libcs/kernels would not be able to run binaries compiled for newer libc. The GCC and GLIBC versions used for every platform may differ a bit, but they are about GCC 12.x and GLIBC 2.24, or not far off. The build with incompatible libc version would usually fail to start.