Microsoft, Azul, and other community members are collaborating to port OpenJDK to MacOS and Windows on the AArch64 chipset. This work coincides with the upcoming availability of ARM-based Macs and aims to have a supported OpenJDK build in approximate alignment to market availability and adoption of the new chip.
"Azul is building an Aarch64 port for MacOS, has drafted a JEP for the work, will do the work in the open as much as possible (limited by Apple's developer kit early access rules), and will contribute the complete work upstream to be included in e.g. OpenJDK 16 or 17. Once we land this upstream, we also intend to build OpenJDK 11 and 8 variants and make sure developers and users have free binary OpenJDK distros available that will work on ARM-based Mac," explains Gil Tene, CTO of Azul, which maintains the freely available Zulu build of OpenJDK across many platforms.
Microsoft’s involvement is driven in part by JVM performance expert Monica Beckwith. Beckwith previously handled runtime performance architecture for ARM and was critical to the development of the G1 garbage collector at Oracle and Sun. Microsoft has previously released OpenJDK on Windows ARM64 with various patches contributed to the open source community.
While the Windows and Mac ports require different compilation targets and code changes, aspects of the underlying platforms can be shared in a uniform way that speeds the project along. Tene explains the timeframe for release, "We hope to get stuff people can use before the 'problem' of ARM-based Macs with no Java becomes 'a thing'." ARM-based Macs are not currently available for standard purchase, but industry review groups like Tom's Hardware expect ARM Macbooks towards the 2021 timeframe. The hardware for Windows ARM devices is limited to the Surface Pro X and a small number of other laptops.
Work to port the Java Runtime Environment (JRE) will benefit Java developers without requiring additional effort to re-code or modify applications. Java code typically follows a pattern that makes any recompilation or modification unnecessary:
A developer writes source code, calling any libraries that they deem appropriate to solve a problem. Libraries are available in JAR files, which hold class file bytecode.
The developer or continuous integration server compiles the source code to bytecode, running unit and integration tests to limit unexpected bugs. All bytecode JAR files are packaged as a distributable component.
When running, the JRE executes the bytecode to determine "hot spots" where performance will be improved through just-in-time compilation to native code.
With this work done through Java vendors like Microsoft and Azul, developers can simply deploy their code to any system for which a JRE is available.
Developers whose applications are deployed as standalone executables must recompile their application with an appropriate runtime target. This includes those who create custom per-application JREs through tools like jlink, or javapackager / jpackage as well as GraalVM native mode.
