Apple Silicon¶

Minecraft 1.8.9 and 1.7.10 were built years before Apple Silicon, and Mojang publishes no Apple Silicon Java for them. From launcher 0.2.7 on, Xol can run them on a native Apple Silicon Java 8 and starts the game again through Rosetta 2 if that does not work. Nothing on this page applies to Intel Macs, Windows or Linux.

This applies from launcher 0.2.7 on. Builds up to 0.2.6 always run the game's Java through Rosetta 2, and have no setting for it.

What has been measured, and what has not¶

The project has not run the native runtime on real Apple hardware. Everything known about it comes from an automated macOS 14 build machine with an Apple M1 processor and no graphics card, where Apple's software renderer draws every frame.

You can produce the missing number on your own Mac; see Compare the two yourself.

The setting¶

Settings ▸ Java ▸ Java runtime for 1.7 / 1.8. The field exists only on an Apple Silicon Mac. It applies to every profile whose Minecraft version needs Java 8, which today is all of them.

A custom Java executable overrides this field. With a custom Java, Xol leaves the game libraries as Mojang publishes them for macOS, which are Intel ones, so on Apple Silicon a custom Java has to be an Intel (x64) Java 8.

While the game runs, the main screen names the runtime in use after the start time. For the native runtime it names Zulu 8 Community JRE 8.0.504 with LWJGL 2.9.4-nightly-20150209 arm64, and says that it runs natively on Apple Silicon without Rosetta. For the Intel runtime it names Mojang's jre-legacy and says that it runs through Rosetta 2 because Mojang publishes no arm64 build of it.

What is swapped¶

Two things change together, because an Apple Silicon Java cannot load an Intel native library.

LWJGL 2.9.4-nightly-20150209 is the build Mojang itself ships for 1.8.9 on Windows and Linux. LWJGL 2 compares its native library with its Java classes when it starts, so the two class-path jars are replaced along with the natives.

The swap is made in memory for that one launch. The version files on disk stay exactly what Mojang and Forge published, so switching between the two runtimes needs no repair.

The controller library (jinput) is not replaced. Minecraft itself never loads it; a mod that used game controllers would find no native library for them on the native runtime.

What is downloaded, and from where¶

Xol bundles and mirrors none of this. Your computer fetches each file from the publisher's own address, the first time a game is started with the native runtime. With the setting on Intel (Rosetta 2), none of these files is fetched.

The pinned checksums:

Java zip        SHA-256  1769ea082fa13ba29403363425716451b04b10f5ae6dba07f7f0a69666197f15
arm64 natives   SHA-256  a14379458c749872a1e183e88edceaab87c762328fb031481d98d0aaed5e6311
arm64 natives   SHA-1    eff546c0b319d6ffc7a835652124c18089c67f36
lwjgl           SHA-1    697517568c68e78ae0b4544145af031c81082dfe
lwjgl_util      SHA-1    d51a7c040a721d13efdfbd34f8b257b2df882ad0

• Every file is fixed by its exact address and checksum inside the launcher. A file whose bytes do not match is discarded and never run.
• github.com is not an allowed download host in general. That one address is allowed, and nothing else on the host can be fetched as a library.
• Azul is used because it publishes a free Java 8 for macOS on Apple Silicon together with its checksums. The checksum Xol pins is the one Azul's own package listing publishes.
• The arm64 natives are a community build, and Xol cannot rebuild them. They come from a fork of the LWJGL 2 source repository. The file is fixed by its checksums, and both libraries inside were checked to be arm64-only.
• Where the files are kept is on File locations.

As with any download, these hosts see your IP address and a user-agent, and nothing else from Xol. See Privacy and data.

The fallback¶

A machine where the native runtime does not work must still be a machine where Minecraft starts. So a native start is watched until the game logs that its window exists, which is the first thing that can fail when Java and the native libraries do not match.

The fallback triggers when:

• the game has not opened its window within 90 seconds, or
• the game exits before the window opens, or
• the native runtime cannot be prepared at all: the Java or the arm64 natives cannot be downloaded, or fail their checksum.

What happens then:

1. What is left of the native attempt is stopped.
2. The same instance is started again with Mojang's x64 Java through Rosetta 2, as 0.2.6 and older did.
3. The instance records the failure and its reason in runtime.json. While the setting is on Automatic, later starts of that instance go straight to the Intel runtime without trying again.
4. The main screen shows one line while the game runs, in place of the start time and runtime:

Minecraft did not start with the Apple Silicon Java runtime, so Xol started it again with the Intel runtime (Rosetta). This profile will keep using the Intel runtime; Repair puts it back to automatic.

With the setting on Apple Silicon (arm64), the second sentence says instead that the next start tries the native runtime again. Hovering over the line shows the runtime in use.

To try the native runtime again on that instance, run Settings ▸ Instance ▸ Repair, which removes the record. Choosing Apple Silicon (arm64) also tries it again, without removing the record.

A launch you cancel while its files are being prepared is not a failure and records nothing. If the Rosetta attempt fails as well, the message you see is the one from the first failure. The fallback needs Rosetta 2 to be installed; see Troubleshooting.

Compare the two yourself¶

The Xol client has a frame counter that is off unless you ask for it. It exists in Xol 1.8.9 and Xol 1.7.10.

Add this to Settings ▸ Java ▸ Extra JVM arguments, with the number of seconds to measure, from 1 to 3600:

-Dxol.bench.seconds=60

Counting starts with the first frame the game draws, the title screen included. The counter writes one line to the game log every ten seconds and a last one when the time is up:

[XolBench] final version=<v> seconds=<s> frames=<n> fps_avg=<f> fps_1pct_low=<f> hud_us_per_frame=<µs> measure_us_per_frame=<µs> hud_share=<%>

Without the argument, or with a value that is not a whole number from 1 to 3600, nothing is set up: no counter exists and nothing extra runs per frame. Remove the argument when you are done.

For a comparison that means something:

1. Use the same instance, the same world and spot, the same window size, the same preset and the same memory for both runs.
2. Set Java runtime for 1.7 / 1.8 to Intel (Rosetta 2), start the game, go to your spot, and let the time run out. Because counting starts at the first frame, choose a time long enough that loading the world is a small part of it, and compare the later ten-second lines as well as the final one.
3. Set it to Apple Silicon (arm64) and do exactly the same.
4. Compare the two final lines. The runtime each run used is in the support log, under "instance last ran on".

The lines are in the game log: logs/latest.log in the instance, or the newest game-….log in the data folder's logs folder. If you measure this on a real Mac, the result is useful to the project either way: contact@xol.dev.

Launcher 0.2.6 and older¶

Up to 0.2.6 the game's Java on Apple Silicon is always Mojang's x64 Java 8 through Rosetta 2, the same way Mojang's own launcher runs these versions. There is no setting, nothing is downloaded from Azul or GitHub, and no runtime.json is written. The launcher itself is a native arm64 app in every version.