AdoptOpenJDK 16 Available
AdoptOpenJDK is happy to announce the immediate availability of AdoptOpenJDK 16. Binaries are available for download of OpenJDK and Eclipse OpenJ9 (with OpenJDK class libraries). As always, all binaries are available free of charge without usage restrictions on a wide range of platforms.
New and Noteworthy
Overview of Java 16
- JEP 338 started the first incubation phase of the Vector API to take advantage of super-fast vector instructions like Intel’s AVX.
- JEP 376 brought concurrent thread-stack processing to ZGC.
- JEP 380 added Unix-domain socket support to channels.
- JEP 386 landed support for using OpenJDK on Alpine Linux with musl libc instead of glibc.
- JEP 387 introduced the Elastic Metaspace, which should help to return memory faster to the operating system.
- JEP 388 introduced support for Windows on ARMv8; a build from AdoptOpenJDK is going to be available soon.
- JEP 389 started the first incubation phase of the Foreign Linker API, making it simpler and safer to interact with native code.
- JEP 390 brought warnings for value-based classes.
- With JEP 392, jpackage, a tool to create native application packages like an .exe, was promoted to a production feature.
- JEP 393 started a third incubation phase of the Foreign-Memory Access API that replaces Unsafe, and more.
- JEP 394 adds pattern matching for instanceof.
- With JEP 395, Records are now production-ready.
- JEP 396 encapsulates additional JDK internals by default.
- JEP 397 started the second preview of sealed classes.
For a complete list of the enhancements (including ones that only impact developers of OpenJDK), see the JDK 16 overview over at OpenJDK.
AdoptOpenJDK for Alpine Linux With musl libc
Alpine Linux is a popular Linux distribution for container workloads because of its small footprint. Contrary to most other Linux distributions, Alpine Linux is not based on the C library created by the GNU project (usually referred to as “glibc”) but uses musl libc instead. So far, OpenJDK has not supported musl libc but only glibc. Therefore, we had to add the GNU C library to our container images based on Alpine Linux, which increased the container images’ size. With AdoptOpenJDK 16, this is no longer necessary. We now have separate variants of AdoptOpenJDK 16 that are purpose-built for musl libc that can be downloaded as a tarball and are also available as ready-made container images.
Removal of 10 Symantec Root Certificates
As part of the general distrust of Symantec root certificates, 10 of them have been removed from AdoptOpenJDK. For details, see the related issue over at the Mozilla Foundation.
One OpenJ9 for All Heap Sizes
So far, AdoptOpenJDK with Eclipse OpenJ9 came in two flavors: “normal” and “large heap” (sometimes called “XL”). The large heap variant was purpose-built for workloads with, well, large heaps. Thanks to recent improvements to OpenJ9, this distinction is no longer necessary. AdoptOpenJDK 16 with Eclipse OpenJ9 is available as a single build that automatically switches between the normal and large heap mode depending on the configured heap size (-Xmx switch). If the heap size is larger than 57 GB, it will automatically enable non-compressed references, which corresponds to the old large heap mode. On AIX and Linux with the metronome garbage collection policy (-Xgcpolicy:metronome), the threshold is at 25 GB instead of 57 GB. Next month, AdoptOpenJDK 8 and 11 with OpenJ9 will get the same capabilities.
Some users might have chosen to use the large heap variants even if their heap was not that large. They can get back that behavior by starting the VM with -Xnocompressedrefs. If you want to know more, see what the Eclipse OpenJ9 documentation has to say about compressed references.
Do you have questions or want to discuss this post? Hit us up on the AdoptOpenJDK Slack workspace!