Native Apple Silicon Support

[fishcharlie.code@…]

Is there any chance we can get a Apple Silicon native build for JOSM? That way it won't have to use Rosetta 2 and will lead to increased performance.

[taylor.smock]

I think it comes down to either (a) someone donating Mac ARM hardware to the JOSM organization (so they can add it as a Github Actions runner) or (b) a JOSM developer having an ARM M1 Mac lying around that they can add to the build process.

Until either (a) or (b) happens, there probably won't be any official ARM M1 Mac builds. For example, I could probably rig up a process to do the build on one of my coworker's laptops (they have an M1 Mac), but it would be better to do it right. For various reasons (can you trust me? Probably. But you shouldn't trust me for security purposes.)

[GerdP]

Is this about the installation package which would contain a different JRE?

[taylor.smock]

Replying to GerdP:

Is this about the installation package which would contain a different JRE?

I believe so.

Specifically, a JRE built for the ARM Macs.

@fishcharlie.code: OpenWebStart may automatically download the "right" architecture. Can you try that?

https://josm.openstreetmap.de/wiki/Download#Webstart

Alternatively, you can download Azul here: ​https://www.azul.com/downloads/?version=java-17-lts&os=macos&architecture=arm-64-bit&package=jre and run the josm.jar file.

[Don-vip]

Replying to taylor.smock:

Until either (a) or (b) happens, there probably won't be any official ARM M1 Mac builds. For example, I could probably rig up a process to do the build on one of my coworker's laptops (they have an M1 Mac), but it would be better to do it right. For various reasons (can you trust me? Probably. But you shouldn't trust me for security purposes.)

I trust you but you're right, there is no chance this is going to happen :D This has to be officially supported by OpenJDK, Azul and Github to happen.

OpenJDK/Azul is done: ​https://www.azul.com/newsroom/azul-announces-support-of-java-builds-of-openjdk-for-apple-silicon/
Github not yet: ​https://github.com/actions/runner/issues/805

[taylor.smock]

Replying to Don-vip:

OpenJDK/Azul is done: ​https://www.azul.com/newsroom/azul-announces-support-of-java-builds-of-openjdk-for-apple-silicon/
Github not yet: ​https://github.com/actions/runner/issues/805

I'm kind of surprised that Github doesn't support Apple Silicon yet (at least as "bring your own runner", somewhat similar to GitLab). I would have assumed that a recompile would have it "just working", but apparently they depend upon .NET. Which recently had a release which supports Apple Arm.
So, GitHub will probably be able to support it in the next year or so.

[matheusgomesms]

Any updates? It seems Github added this in Sep 22: ​https://github.com/actions/runner/issues/805

[taylor.smock]

From that issue (~1 month ago),

As per the roadmap we are targeting some time later this year for GitHub hosted M1 support :)

With that said, self-hosted Apple arm runners can be done. While I could probably get my employer to let me put a runner on one of our extraneous machines, there are some security concerns with that. What happens if that machine gets hacked and the JOSM signing key gets leaked?

[matheusgomesms]

It seems now Github support M1 hosted runners? ​https://github.com/github/roadmap/issues/528

[taylor.smock]

Yes, but only on their larger runners. I don't know what the pricing scheme is going to be after the beta period ends, and I don't want to have to temporarily disable a build platform while we figure out whether or not the pricing scheme will work for us. The lead maintainers may have a different opinion on that.

Of specific note from ​GitHub:

Note: Included minutes cannot be used for larger runners. These runners will always be charged for, including in public repos. For more information, see "About billing for GitHub Actions."

Once arm macs are available for building on with a standard ("free to us") size runner, I think we'll be able to turn it on.

As of writing, the per-minute rate for the m1 mac is $0.16. I don't have the numbers for how long a build would take on an M1 Mac, but figure ~1 hour for the build, which comes out to $9.60/build. And we do a build with almost every commit (every push, which usually comes out to every commit). By comparison, a higher tier linux runner is .064/minute, or $3.84/hour.

We could do some changes so that we only generate the packages after the build and test steps complete, but that would take a little bit of time and experimentation.

We really just need to have one build step per platform + build steps for multiple java versions on a single platform (15 -> 10 jobs). We could technically build the jar on one platform and reuse it on the others, but building with multiple java versions will let us know if we use something illegal in a newer version of java. If we were to compile the class files for that version (I should fix that). And compiling on multiple platforms lets us ensure that the occasional contributor can still build on a platform the core developers don't use.
We still need to do the tests on every platform + java combination (15 jobs, 3 platforms * 5 java versions). This is where most of the time is anyway (20-30 minute test runs, although there might be a way to reduce it to 10 minutes or so).
We still need to do the build and package steps (Windows/macOS only, 10(?) jobs, ~2 minutes each, if I had to guess -- both are failing due to signing certificate issues).

[matheusgomesms]

Ah that's true! They expect regular-size runners available by Jan-Mar 24. Let's keep an eye: ​https://github.com/actions/runner-images/issues/8439#issuecomment-1755601587 and ​https://github.com/github/roadmap/issues/819

[matheusgomesms]

It seems available now, finally: ​https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/

​https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

[taylor.smock]

Thanks for poking this ticket.

We'll have to update the runs-on or wait for Q2:

The macOS 12 runner image will remain latest until migration of the latest YAML workflow label to macOS 14 in Q2 FY24 (April – June 2024). [...]

Of specific note, it looks like we will no longer have x86 installers available for JOSM for mac once that change occurs. I might be able to work around that (by installing an x86 version of Java in the action).

JDK issue to follow: ​https://bugs.openjdk.org/browse/JDK-8266259 .

There is also a hacky workaround here: ​https://incenp.org/notes/2023/universal-java-app-on-macos.html ; this might work for us, if I can find a good way to not have to compile c code. Maybe arch will work, but I'll have to see how it works.

I think I can have a shell script that does the following:

arch -arm64 bash -c 'echo arm'
if [ $? == 0 ]; then arch -arm64 java -jar josm-custom.jar; else java -jar josm-custom.jar; fi

[taylor.smock]

Universal app generation (note: currently requires a JOSM install at /Applications -- this is also the only (current) part that requires a mac)

[taylor.smock]

Try arch -arm64 first and fall back to whatever the OS feels like doing that day.

[taylor.smock]

Add auto updates

[anonymous]

Hi JOSM Team,

I'm checking in to see how things are going with getting JOSM.app to run natively on Apple Silicon. Any updates on that front? And if there are, can you give me an idea of when we might expect the first build for ARM platform?

JOSM is an amazing editor, thank you for your work in maintaining this software!

[taylor.smock]

Ticket retargeted after milestone closed

[taylor.smock]

Replying to anonymous:

I'm checking in to see how things are going with getting JOSM.app to run natively on Apple Silicon. Any updates on that front? And if there are, can you give me an idea of when we might expect the first build for ARM platform?

The hard part here is I don't have both an intel machine and an arm machine to fiddle with. I can start building on arm, but I don't want to until I know that x86_64 will continue working. Ideally there would be just one application bundle for both arm and x86 processors so that users won't have to care which one they grab.

JOSM is an amazing editor, thank you for your work in maintaining this software!

You are welcome.

[taylor.smock]

In 19030/josm:

Fix #21533, see #23600: Native Apple Silicon Support

When building on macOS, the macos-jpackage.sh script now takes two arguments:

1. The JOSM revision
2. An additional JDK to build against (this should be of a different architecture)

If an additional JDK is specified, it is assumed that it is a different
architecture, and the two built apps are combined using lipo for a universal binary.

ant.yml does have some changes to make it easier to debug packaging issues in
PRs; the PR does still need to upload the specific package and add its branch to
the triggers.

[taylor.smock]

In 19031/josm:

See #21533: Native Apple Silicon Support

Try to fix code signatures for merged binaries.

Options largely came from ​https://github.com/openjdk/jdk21u/blob/master/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java#getCodesignArgs

[taylor.smock]

In 19032/josm:

See #21533: Native Apple Silicon Support

Try to fix code signatures for merged binaries (again).