Add Apple M1 build.

[syhily]

[ppalaga]

Blocked by https://github.com/actions/virtual-environments/issues/2187

[syhily]

Since the mvnd is written in Java, we could provide a jvm based distribute as a universal version.

[ppalaga]

we could provide a jvm based distribute as a universal version.

That exists already. Download whichever build and use mvnd.sh instead of mvnd. The shell script starts a full JVM on the client side so it is a bit slower than the native client of course.

[syhily]

I have changed the homebrew install scripts for using the mvnd.sh instead of mvnd on Apple M1. Could this PR be merged into the master.

[gnodet]

The PR for the home-brew recipe has been merged.

[ppalaga]

BTW, this GraalVM issue states that native executables for mac x86_64 are runnable on Apple silicon using Rosetta Translation Environment

It would be interesting to compare the speed of the translated binary with mvnd.sh + JVM. BTW, isn't the JVM on Mac AArch64 also just a Rosetta translation?

[ppalaga]

Reopening, because we want a Mac@AArch64 build when all the parts are available.

This is also blocked by https://github.com/oracle/graal/issues/2666

[davsclaus]

There is also jansi

~/workspace/camel master ❯ mvnd clean install -P fastinstall
Exception in thread "main" java.lang.ExceptionInInitializerError
	at org.mvndaemon.mvnd.client.DefaultClient.main(DefaultClient.java:91)
Caused by: java.lang.RuntimeException: Unable to load jansi native library
	at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:62)
	at org.fusesource.jansi.internal.CLibrary.<clinit>(CLibrary.java:30)
	... 1 more
Caused by: java.lang.Exception: No native library found for os.name=Mac, os.arch=aarch64, paths=[/opt/homebrew/Cellar/mvnd/0.4.2/libexec/mvn/lib/jansi-native/Mac/aarch64:/opt/homebrew/Cellar/mvnd/0.4.2/libexec/mvn/lib/jansi-native:/Users/davsclaus/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]
	at org.fusesource.jansi.internal.JansiLoader.loadJansiNativeLibrary(JansiLoader.java:333)
	at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:60)
	... 2 more

[gnodet]

There is also jansi

~/workspace/camel master ❯ mvnd clean install -P fastinstall
Exception in thread "main" java.lang.ExceptionInInitializerError
	at org.mvndaemon.mvnd.client.DefaultClient.main(DefaultClient.java:91)
Caused by: java.lang.RuntimeException: Unable to load jansi native library
	at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:62)
	at org.fusesource.jansi.internal.CLibrary.<clinit>(CLibrary.java:30)
	... 1 more
Caused by: java.lang.Exception: No native library found for os.name=Mac, os.arch=aarch64, paths=[/opt/homebrew/Cellar/mvnd/0.4.2/libexec/mvn/lib/jansi-native/Mac/aarch64:/opt/homebrew/Cellar/mvnd/0.4.2/libexec/mvn/lib/jansi-native:/Users/davsclaus/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]
	at org.fusesource.jansi.internal.JansiLoader.loadJansiNativeLibrary(JansiLoader.java:333)
	at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:60)
	... 2 more

This would require a fix for https://github.com/multiarch/crossbuild/issues/51 so that jansi could have a M1 version.

[electrum]

I was able to run mvnd on M1 by using an x86 JDK:

JAVA_HOME=/tmp/zulu16.32.15-ca-jdk16.0.2-macosx_x64 mvnd clean install -DskipTests

However, even after the daemon was warmed up, it was still slower than running mvn using the native ARM JDK. My test run was only building four sequential modules, so there might still be benefit to non-native mvnd on a larger project.

[electrum]

I think we can close this as it was fixed in #502. I’ve been happily using the 0.7.0 release successfully on my M1 Mac mini!

[davsclaus]

I am on M1 and mvnd 0.7.0 works there.

[gnodet]

Well, it works, but it's still using the Apples' Rosetta 2 translation layer. I'd rather keep that one opened until GraalVM supports M1 directly.

[ppalaga]

There is some update in https://github.com/oracle/graal/issues/2666#issuecomment-1010183689 It says

JDK17 / labs-openjdk-17 supports darwin-aarch64 today

but it is not clear to me whether the changes are released already and which release it is.

[ppalaga]

This comment https://github.com/oracle/graal/issues/2666#issuecomment-1074884020 states

I'm pleased to announce that we uploaded the first snapshot containing darwin-aarch64: https://github.com/graalvm/graalvm-ce-dev-builds/releases/tag/22.1.0-dev-20220321_2332

The following components are available for this platform:

• JVM with libgraal
• native-image
• JavaScript
• Espresso

This would make it at least possible to compile locally on a darwin-aarch64 machine.

[orpiske]

This comment oracle/graal#2666 (comment) states

I'm pleased to announce that we uploaded the first snapshot containing darwin-aarch64: https://github.com/graalvm/graalvm-ce-dev-builds/releases/tag/22.1.0-dev-20220321_2332 The following components are available for this platform:

• JVM with libgraal
• native-image
• JavaScript
• Espresso

This would make it at least possible to compile locally on a darwin-aarch64 machine.

I am trying it to see how it goes 🤞

[orpiske]

@ppalaga it built fine. I tried building Camel with it (cached) and it went fine. Performance was nice too (10 core M1 Pro building it roughly with the same duration as a Ryzen 9 3900XT).

[orpiske]

I know support is not official yet, but sharing my experience in the hope it will eventually be useful for when there is an official release.

One thing I noticed is that the build for ARM doesn't seem to respect the mvnd.threads setting or the -T flag. Using -T 0.5C here, still causes it to use all cores.

[ppalaga]

A new issue for OSX arm64 runners hosted by GitHub was recently added to GH public roadmap: https://github.com/github/roadmap/issues/528

I think this issue won't move without that one.

[ppalaga]

Citing from https://github.com/actions/virtual-environments/issues/2187#issuecomment-1164711613

Have contacted GitHub support and they hope to have it in place by end of FY2022.

[orpiske]

Citing from actions/virtual-environments#2187 (comment)

Have contacted GitHub support and they hope to have it in place by end of FY2022.

Ouch, that's quite a long time. I'm wondering if it would be feasible to provide mvnd on homebrew. I don't know much about it, so I hope I am not talking non-sense here, but if homebrew builds from source that would solve the need for a while.

[mthmulders]

[...] I'm wondering if it would be feasible to provide mvnd on homebrew. I don't know much about it, so I hope I am not talking non-sense here, but if homebrew builds from source that would solve the need for a while.

AFAIK, Homebrew doesn't provide a build service. They have manifests (in fact, Ruby files) that describe how to download (and optionally build) software on the users machine.

[orpiske]

[...] I'm wondering if it would be feasible to provide mvnd on homebrew. I don't know much about it, so I hope I am not talking non-sense here, but if homebrew builds from source that would solve the need for a while.

AFAIK, Homebrew doesn't provide a build service. They have manifests (in fact, Ruby files) that describe how to download (and optionally build) software on the users machine.

Yeah, that's what I was thinking of (sorry, I did not explain it well). Just have it build on the user's computer with the help of brew.

[kameshsampath]

I am still waiting for this on M1, doing a build from source on M1 will help or I need to wait for official release?

[ppalaga]

doing a build from source on M1 will help or I need to wait for official release?

@orpiske 's script is still be the best way to get a working native mvnd on Apple Silicon Mac https://www.orpiske.net/2022/07/try-apache-maven-daemon/

[mprimeaux]

brew install mvndaemon/homebrew-mvnd/mvnd works on both my Mac Studio (M1 Ultra) and MacBook Pro (M1 Max) for Java 9 and greater.

Unfortunately, Java 8 (Temurin Open JDK) fails with the following:

JAVA_HOME is not set. Setting JAVA_HOME to the location of your Java installation.
JAVA_HOME is set to /Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home.
Using 'mvnd' to build workload.
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/mvndaemon/mvnd/client/DefaultClient has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)
make: *** [compile] Error 1

[ppalaga]

@mprimeaux for running mvnd.sh with Java 8, please see https://github.com/apache/maven-mvnd/issues/669#issuecomment-1205335100 and https://github.com/apache/maven-mvnd/issues/547#issuecomment-1004889625

[gnodet]

@mprimeaux Also, a candidate release of mvnd 0.8.2 with M1 builds is available for review at https://dist.apache.org/repos/dist/dev/maven/mvnd/0.8.2/. It would be nice to have some feedback for the M1 builds.

[ppalaga]

How were those M1 builds produced, @gnodet ?

[gnodet]

How were those M1 builds produced, @gnodet ?

On a Mac mini M1 that MacStadium has freely provided to me for the maven project.