Temurin-build: Provide native builds for ARM based Macs

[hendrikebbers]

At WWDC20 Apple announced to move from Intel to ARM chips for Mac hardware. For the Java Community it will be important to support Java on those new devices. At Adopt we should provide native Java builds for the new hardware if possible.
This issue can be used to collect information about porting Java to ARM on Mac.

[hendrikebbers]

WWDC 2020 session "Port your Mac app to Apple Silicon": https://developer.apple.com/videos/play/wwdc2020/10214/

[karianna]

Will need to see Apple's Mac OS X Port arrive upstream and get a developer kit

[hendrikebbers]

One open point is the support for the new Metal rendering pipeline of Apple. OpenGL is deprecated in MacOS and I assume that it won't be supported on ARM based Macs anymore (verification is needed). Since OpenGL is already deprecated for some time the OpenJDK will take care of that by implementing a new rendering pipeline for Metal. You can find more info in JEP 382 and the Lanai project page. An early access build can be found here. How much of project Lanai must be refactored when targeting ARM is unknown.

[hendrikebbers]

It is not clear how Java 8 and 11 will be handled. Even if we will get commits to the upstream to have OpenJDK working on ARM based Macs all this must be back ported if Java 8 and 11 LTS versions will be supported.

I do not know how this is handled for similar projects like https://openjdk.java.net/jeps/237. Maybe @jerboaa can give an answer? Next to this Microsoft published an article about the work on OpenJDK for Win/ARM. Repo can be found here. Maybe @karianna can say how that will be handled for 8 / 11?

[aahlenst]

Regading OpenGL, quoting https://developer.apple.com/documentation/xcode/porting_your_macos_apps_to_apple_silicon:

OpenGL is deprecated, but is available on Apple silicon.

[jerboaa]

It is not clear how Java 8 and 11 will be handled. Even if we will get commits to the upstream to have OpenJDK working on ARM based Macs all this must be back ported if Java 8 and 11 LTS versions will be supported.

I do not know how this is handled for similar projects like https://openjdk.java.net/jeps/237. Maybe @jerboaa can give an answer?

I'd like to caution to not speculate on this at this stage. It's not clear what comes of this Mac on ARM announcement in terms of OpenJDK. So speaking of a backport of something which doesn't exist is way too early ;-)

Speaking for JEP 237 (Linux Aarch64 port integration into mainline). Originally the Aarch64 port project was incepted as an OpenJDK project. This is where development happened. That was well before JEP 237 happened. At some point it got proposed for inclusion into mainline. That's what JEP 237 is. It targeted JDK 9. Thus, OpenJDK 9+ has Aarch64 as supported architecture (on Linux) in mainline. The OpenJDK 8u code for Aarch64 is still maintained in an Aarch64 ports project's repository[1]. That is, Aarch64 support in OpenJDK 8u isn't in mainline OpenJDK 8u. Though, it's been proposed to get integrated into mainline OpenJDK 8u before and there is interest to get it integrated. Question is when that will happen.

[1] http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/

[hendrikebbers]

@jerboaa THX for that feedback. I do not want to speculate. I just collect information to understand the big picture :)

[hendrikebbers]

adding https://github.com/AdoptOpenJDK/openjdk-support/issues/146

[hendrikebbers]

Thread in JavaFX Dev Mailing List: https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-July/026949.html

[hendrikebbers]

http://openjdk.java.net/jeps/8251280

[hendrikebbers]

SWT issue to provide universal binaries: https://bugs.eclipse.org/bugs/show_bug.cgi?id=565690

[vielmetti]

"JEP 391: macOS/AArch64 Port" - http://openjdk.java.net/jeps/391 - references JEP 237 (linux/aarch64) and JEP 388 (Windows on Arm).

[hendrikebbers]

JDK Bugdatabase issue: https://bugs.openjdk.java.net/browse/JDK-8253795

[karianna]

Sneak preview.. https://github.com/microsoft/openjdk-aarch64/releases/tag/16-ea%2B10-macos

[hendrikebbers]

If someone would have told me 5 years ago that Microsoft provides the first Java 16 build for ARM based Macs ... :D

[VladimirKempik]

openjdk8/11/13 builds are available from azul - https://www.azul.com/downloads/zulu-community/?os=macos&architecture=arm-64-bit&package=jdk

[davidgiga1993]

Will there be a "universal binary" version available?
I'm asking because I use the jpackage utility to bundle my app and ideally there should be one bundle which runs on x86 and arm macs.
Or will I need to manually create a universal binary package?

[VladimirKempik]

Will there be a "universal binary" version available?
I'm asking because I use the jpackage utility to bundle my app and ideally there should be one bundle which runs on x86 and arm macs.
Or will I need to manually create a universal binary package?

Hello

I'm not sure if it's even possible for 11+, considering the module system

[davidgiga1993]

Will there be a "universal binary" version available?
I'm asking because I use the jpackage utility to bundle my app and ideally there should be one bundle which runs on x86 and arm macs.
Or will I need to manually create a universal binary package?

Hello

I'm not sure if it's even possible for 11+, considering the module system

Why shouldn't it be? I would assume you can just merge the arm and x86 binary and libs into universal versions using the lipo utility.
I don't have a M1 but I could try building a universal jvm.

[VladimirKempik]

don't forget to unpack some modules which has binaries ( like libjvm), lipo and then repack the modules.

[drej1]

Hi there, is there any roadmap when AdoptOpenJDK will support apple silicon architecture? Thanks

[aahlenst]

is there any roadmap when AdoptOpenJDK will support apple silicon architecture

The ARM port for Apple Silicon is in development at OpenJDK, see http://openjdk.java.net/jeps/391. As long as it isn't finished, it's unlikely that there's going to be a release from AdoptOpenJDK. We would like to provide nightly-builds soon-ish, but the build jobs haven't been set up yet (PRs are welcome).

[murkle]

ARM-64 builds are already available here (Java 8, 11, 13, 16)

https://www.azul.com/downloads/zulu-community/?os=macos&architecture=arm-64-bit&package=jdk

[hendrikebbers]

@davidgiga1993 @VladimirKempik good question about universal binaries based on jlink. I assume that all internal libraries of the JVM must be universal libs.

[VladimirKempik]

there should be improvement to JVM to improve CDS to look for jsa for specific arch, otherwise currently (if universal binaries are made) they will try to share one classes.jsa file, and that will brake things a bit.

[kkeker]

Some other programming languages are based exactly on your JVM version and expect to build from you, for example, Ballerina.IO - https://github.com/ballerina-platform/ballerina-lang/issues/27585

[austinarchibald]

Updated to new m1 mac mini and can't run a .jar file I typically use. I installed the Azul ARM-64 Build for 11. Any guidance/ideas?

java -jar /Users/austin/Downloads/updatetool-gui-mac-1.0.0.jar 
Loading library prism_es2 from resource failed: java.lang.UnsatisfiedLinkError: /Users/austin/.openjfx/cache/13/libprism_es2.dylib: dlopen(/Users/austin/.openjfx/cache/13/libprism_es2.dylib, 1): no suitable image found.  Did find:
    /Users/austin/.openjfx/cache/13/libprism_es2.dylib: mach-o, but wrong architecture
    /Users/austin/.openjfx/cache/13/libprism_es2.dylib: mach-o, but wrong architecture
java.lang.UnsatisfiedLinkError: /Users/austin/.openjfx/cache/13/libprism_es2.dylib: dlopen(/Users/austin/.openjfx/cache/13/libprism_es2.dylib, 1): no suitable image found.  Did find:
    /Users/austin/.openjfx/cache/13/libprism_es2.dylib: mach-o, but wrong architecture
    /Users/austin/.openjfx/cache/13/libprism_es2.dylib: mach-o, but wrong architecture
    at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
    at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
    at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
    at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
    at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
    at java.base/java.lang.Runtime.load0(Runtime.java:768)
    at java.base/java.lang.System.load(System.java:1837)
    at com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:214)
    at com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:194)
    at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:135)
    at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:53)
    at com.sun.prism.es2.ES2Pipeline.lambda$static$0(ES2Pipeline.java:68)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at com.sun.prism.es2.ES2Pipeline.<clinit>(ES2Pipeline.java:50)
    at java.base/java.lang.Class.forName0(Native Method)
    at java.base/java.lang.Class.forName(Class.java:315)
    at com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
    at java.base/java.lang.Thread.run(Thread.java:834)
Loading library prism_sw from resource failed: java.lang.UnsatisfiedLinkError: /Users/austin/.openjfx/cache/13/libprism_sw.dylib: dlopen(/Users/austin/.openjfx/cache/13/libprism_sw.dylib, 1): no suitable image found.  Did find:
    /Users/austin/.openjfx/cache/13/libprism_sw.dylib: mach-o, but wrong architecture
    /Users/austin/.openjfx/cache/13/libprism_sw.dylib: mach-o, but wrong architecture
java.lang.UnsatisfiedLinkError: /Users/austin/.openjfx/cache/13/libprism_sw.dylib: dlopen(/Users/austin/.openjfx/cache/13/libprism_sw.dylib, 1): no suitable image found.  Did find:
    /Users/austin/.openjfx/cache/13/libprism_sw.dylib: mach-o, but wrong architecture
    /Users/austin/.openjfx/cache/13/libprism_sw.dylib: mach-o, but wrong architecture
    at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
    at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
    at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
    at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
    at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
    at java.base/java.lang.Runtime.load0(Runtime.java:768)
    at java.base/java.lang.System.load(System.java:1837)
    at com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:214)
    at com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:194)
    at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:135)
    at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:53)
    at com.sun.prism.sw.SWPipeline.lambda$static$0(SWPipeline.java:42)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at com.sun.prism.sw.SWPipeline.<clinit>(SWPipeline.java:41)
    at java.base/java.lang.Class.forName0(Native Method)
    at java.base/java.lang.Class.forName(Class.java:315)
    at com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
    at java.base/java.lang.Thread.run(Thread.java:834)
Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
    at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
    at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244)
    at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260)
    at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
    at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
    at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
    at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
    at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
    at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
    ... 1 more
Exception in thread "main" java.lang.RuntimeException: No toolkit found
    at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272)
    at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
    at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
    at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
    at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
    at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
    at java.base/java.lang.Thread.run(Thread.java:834)

Java version:

java -version
openjdk version "11.0.9.1" 2020-11-04 LTS
OpenJDK Runtime Environment Zulu11.43+1021-CA (build 11.0.9.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.43+1021-CA (build 11.0.9.1+1-LTS, mixed mode)

[VladimirKempik]

you are trying to use cached openjfx mac_intel libraries with mac_arm java.

there is no openjfx for mac_arm java yet.

[solussd]

Is there a timeline for an OpenJFX port to Apple Arm?

[aahlenst]

Umbrella issue for Apple Silicon support for OpenJFX: https://bugs.openjdk.java.net/browse/JDK-8257222.

[VladimirKempik]

it's already out for two months, from different vendor tho.
As of JEP-391, it won't be integrated this month.

[aahlenst]

AdoptOpenJDK does not have a pre-release ready for Apple Silicon and I assume it's going to take some time until we do. As @VladimirKempik said, it doesn't look like http://openjdk.java.net/jeps/391 (which is the basis of the work happening at OpenJDK) might make 16 (due mid of March). So 17 (due mid of September) looks more likely. Backports are a totally different story. Azul has builds of Zulu ready for Apple Silicon that are, as far as I understand, based on custom patches they developed.

[ppetrosh]

Yes, that's right, Azul has the builds of Zulu ready for Apple Silicon. And we are happy to investigate helping out here. Just let me know.

[aahlenst]

@ppetrosh Thanks a lot, very kind. We're basically waiting for a public branch to appear in OpenJDK. Is there already one? I've only seen that the JEP has been proposed.

[VladimirKempik]

JEP-391 was integrated into jdk17

now everyone can build 17ea for macarm

[aahlenst]

Let's get going.

• [x] Ensure that it can be compiled with openjdk-build.
• [x] Adapt the build farm scripts in openjdk-build (in progress)
• [x] Define pipeline jobs (draft PR: https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/113)
• [x] Organize build machines (https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/2092)
• [x] Organize test machines (https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/2093)
• [ ] Ensure that our testing works (https://github.com/AdoptOpenJDK/openjdk-tests/issues/2421)

[sxa]

Testing executes although work will be done to make it pass all the suites. Closing this as https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk/job/jdk-mac-arm64-hotspot/ will now run on a regular basis.

[devLotto]

@sxa Are you sure the artifacts in there contain arm64 binaries? file java shows Mach-O 64-bit executable x86_64 for me for build 35.

[gdams]

Hmm that's a bit worrying, let me double check again

[gdams]

@devLotto thanks for reporting, PR to fix here: https://github.com/AdoptOpenJDK/openjdk-build/pull/2573

[gdams]

@devLotto can you confirm that this is now fixed on your end? Thanks