275

Will there need to be a special release of OpenJDK to support the new Apple Silicon chips?

I see that there are currently downloads of the JDK for macOS/OS X, but these seem to only be for x86 processors. Is that correct? If so, where can I download a version of OpenJDK for the M1?

Denis Rozhnev
  • 2,547
  • 1
  • 14
  • 15
Thar
  • 2,956
  • 2
  • 10
  • 9
  • 4
    I followed the youtube video for the JDK installation, https://www.youtube.com/watch?v=pZjGom2qTEA. It is working. – jrh Dec 24 '20 at 18:54
  • 8
    Native Apple/Arm64 versions are now available on `brew`, so you should be able to just do `brew install java`, provided you install `brew` natively without using Rosetta 2. – Joshua Pinter Jan 17 '22 at 17:24
  • https://medium.com/@kirebyte/using-homebrew-to-install-java-jdk11-on-macos-2021-4a90aa276f1c works for me. – Wahab Khan Jadon Oct 04 '22 at 07:17

16 Answers16

184

A command line approach (thanks to the Homebrew team and the hard work of @vladimir-kempik and other openjdk contributors on the JEP-391 branch)

# Install Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Install OpenJDK
brew install openjdk

Verify it's installed:

$(brew --prefix openjdk)/bin/java --version

Verify it's for the arm64 hardware:

file $(brew --prefix openjdk)/bin/java     
# /opt/homebrew/opt/openjdk/bin/java: Mach-O 64-bit executable arm64

Note: To install openjdk system-wide, follow the on-screen instructions provided by Homebrew.

tresf
  • 7,103
  • 6
  • 40
  • 101
  • 6
    this was the correct answer – mesqueeb Nov 13 '21 at 11:13
  • 19
    this also works for java 11 without any problem `brew install openjdk@11` and `file $(brew --prefix openjdk@11)/bin/java` - Apple MacBook Pro 2021 - M1 Pro (10 Cores) - using homebrew is for me the preferable option over other approaches – flohall Dec 09 '21 at 10:35
  • 4
    OpenJDK 17 is the first java version officially supporting the M1 architecture – Janos Vinceller Jan 06 '22 at 19:55
  • 1
    $(brew --prefix openjdk)/bin/java --version. this works but java --version does not work... I guess I need to set the java home is it? – MrSham Jan 08 '22 at 04:38
  • `$(brew --prefix openjdk)/bin/java --version` should work fine. If for some reason your Java version is older, you may need `-version` instead of `--version` (one dash). – tresf Jan 08 '22 at 15:43
  • How do you set JAVA_HOME with this answer? java -v doesn't work? – Justin Furuness Jan 26 '22 at 18:09
  • 15
    @JustinFuruness if `JAVA_HOME` is a hard requirement, you can do `export JAVA_HOME="$(brew --prefix openjdk)/libexec/openjdk.jdk/Contents/Home"` although `brew info openjdk` contains instructions for configuring the system to find it, quoting: `For the system Java wrappers to find this JDK, symlink it with...` (the exact command is specific to your system, printed by Homebrew). – tresf Jan 28 '22 at 03:10
  • Running `brew install openjdk@8` fails with `Error: openjdk@8: no bottle available!` on the M1. So it doesn't look like JDK8 can be installed via `brew` on the M1 at this point. – Karthic Raghupathi Jul 18 '22 at 21:31
  • 1
    @tresf thank you, I spent the last 3 hours chasing my tail. your comment for how to add JAVA_HOME finally solved it for me – Dan Horton Dec 20 '22 at 09:25
  • I just did brew install java11 and followed the instructions to update env variables in .zshrc file – Khuram Niaz Feb 02 '23 at 22:23
  • @KhuramNiaz `java11` is an alias for `openjdk@11`. – tresf Feb 02 '23 at 23:44
125

Yes.

On this page: AdoptOpenJDK Latest Releases you can select 'macOS' from the 'Operating System' dropdown, and then from 'Architecture', it's currently only x64, but soonish there should be AArch64 or ARM64 (those are usually the shortcodes for 64-bit ARM). Possibly, as Apple no doubt has a bunch of extensions built into their M1 designs, and Apple gets its own.

If you instead leave Operation System on 'any', you'll note aarch64 is in there, and this gets you to a Linux release for ARM processors. That (probably) won't run on macOS on M1 hardware, but that's 95% of the work already done.

So: It's not there yet, but note that JDKs for ARM have been available for more than decade, and whilst JDK 15 has dropped support for a bunch of exotic OS/architecture combinations (such as Solaris), ARM development has always remained at least partially relevant (even if so far it's mostly an Oracle commercial license offering). That is to say: It should not be a herculean effort to create an adoptopenjdk release that runs on M1s natively, so presumably, it will happen. But, it's an open source effort, so if you're anxious, by all means, read up and contribute :)

Apple has not given any details on this architecture whatsoever until November 10th 2020, unless you bought a development kit box for it (a Mac Mini with an A14 chip, which isn't an M1 chip, but close enough I guess), and signed a big NDA.

As a rule, open source projects will run as fast as possible in the opposite direction if you wave an NDA around, so if you dislike this state of affairs, I don't think it's wise to complain to adoptopenjdk or other packagers and open source projects about it :)

Fortunately, now it's out, and an NDA is no longer required. My assumption is that the ARM branch of the OpenJDK source code + the macOS bits that already exist for the macOS x64 release can be combined rather easily once someone with some familiarity with the OpenJDK source code has an M1-based macOS system to test it on, which should mean an adoptopenjdk macos-aarch64 release should be here within the month.

But, open source. You didn't pay them, you have no contract, and they don't owe it to you. Donate to the effort or contribute a pull request if you want it to go faster.

UPDATE:

  • Azul's M1 OpenJDK builds
  • Microsoft's (yes, really) GitHub source repo for an early access OpenJDK16 build for macOS on AArch64. Note that Microsoft's been working on the OpenJDK branch of AArch64 (for ARM-based Windows 10) for a while, which goes back to: A lot of the hard work was already done.
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
rzwitserloot
  • 85,357
  • 5
  • 51
  • 72
  • 1
    Thank you! , FYI https://bugs.openjdk.java.net/browse/JDK-8251280 – Thar Nov 11 '20 at 14:21
  • 1
    this is only a [JEP](https://openjdk.java.net/jeps/391) at the moment. – Eugene Nov 12 '20 at 02:55
  • 3
    Running gradle didn't work on Microsoft's preview build. Reported it here https://github.com/openjdk/aarch64-port/issues/8 – Felipe Lima Nov 25 '20 at 05:49
  • Sorry to latch on to this... does anyone know what exactly `System.getProperty("os.arch")` reports on macOS for ARM? I'm trying to detect the arch. Thanks! – Hendrik Jan 25 '21 at 14:17
  • Regarding `System.getProperty("os.arch")`, please see [here](https://stackoverflow.com/q/66410522/942774). Thanks. – Hendrik Mar 02 '21 at 12:26
  • 3
    This post says "soonish", but it's been 9 months and the Adopt links are no more helpful than they were when they were originally posted. The `aarch64` explanation is helpful, since it's not obvious to most M1 users that these terms are synonymous, but that first link is still not helpful and should be edited out until the Adoptium team can produce M1 artifacts. – tresf Aug 17 '21 at 16:07
  • In regards to vendor-supplied versions, I'd recommend adding Bell-Soft and OpenJDK from Homebrew to the list to make it more complete. Homebrew steps provided [here](https://stackoverflow.com/a/66891978/3196753) if you'd like to cross-link. `as apple no doubt has a bunch of extensions built into their M1 designs, apple gets its own.` AFAIR, Apple was actually building the inferior "zero assembly" builds at launch and it was the Zulu's and Microsoft's rushing JEP-391 forward. – tresf Aug 17 '21 at 16:09
  • I would strongly recommend removing Microsoft's build or changing it to point at the new location [here](https://docs.microsoft.com/en-us/java/openjdk/download). The one linked is missing `JavaNativeFoundation.framework`, which will fail when using any libraries which link to it, e.g. `libawt.dylib`. I've reported this directly to the MS team shortly after release -- months and months ago (using official and unofficial reporting techniques) but it still hasn't been corrected. The new MS builds don't suffer this problem. Azul, Bell-Soft and Homebrew builds also do not suffer this problem – tresf Aug 17 '21 at 16:29
  • 3
    Please note that the project OpenJDK has moved to Eclipse Fondation and now the new website is : [https://adoptium.net](https://adoptium.net) – jpmottin Dec 03 '21 at 19:14
  • 3
    "Soonish" is finally here. The Adoptium project recently published their first M1 release for Java 17. https://adoptium.net/releases.html?variant=openjdk17&jvmVariant=hotspot. – tresf Dec 17 '21 at 03:05
  • 1
    I had no issues with Azul's Open Jdk. Works like a charm! – hypercube Feb 14 '22 at 08:54
  • This answer was obviously very helpful to many people however it's no longer particularly relevant given that the official builds are available. Perhaps consider noting this at the beginning of the answer. – Madbreaks Jan 10 '23 at 18:39
  • @Madbreaks The oracle releases should not be considered as intrinsically superior, which the name 'official build' seems to give to them. Coretto, Adoptium, etc - these are all just as official. – rzwitserloot Jan 10 '23 at 23:52
51

Azul is offering macOS ARM builds of OpenJDK on their website in the Downloads section. I haven’t tried them out yet though, but Azul have been long-time JDK developers.

Once you unpack the Azul JDK, you have to rummage around inside of it until you find the zulu-11.jdk directory (assuming you've downloaded JDK 11), which you then copy to /Library/Java/JavaVirtualMachines.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Ming-Yee Iu
  • 844
  • 6
  • 5
42
brew install openjdk

In my case, after installing OpenJDK successfully on MacBook Air (M1), the java command still did not work. I fixed it by

brew info openjdk

Then there is a command like

For the system Java wrappers to find this JDK, symlink it with
  sudo ln -sfn /opt/homebrew/opt/openjdk/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk.jdk

Execute this command and the java command works.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Linh
  • 57,942
  • 23
  • 262
  • 279
24

You can install the Java JDK using sdkman (see sdkman install):

vim .sdkman/etc/config

Set sdkman_rosetta2_compatible=false (see sdkman config)

After that, you will see a list of compatible with M1 JDKs:

sdk list java

================================================================================
Available Java Versions
================================================================================
 Vendor        | Use | Version      | Dist    | Status     | Identifier
--------------------------------------------------------------------------------
 Azul Zulu     |     | 16.0.1       | zulu    |            | 16.0.1-zulu
               |     | 11.0.11      | zulu    |            | 11.0.11-zulu
               |     | 8.0.292      | zulu    |            | 8.0.292-zulu
 BellSoft      |     | 16.0.1       | librca  |            | 16.0.1-librca
               |     | 11.0.11      | librca  |            | 11.0.11-librca
               |     | 8.0.292      | librca  |            | 8.0.292-librca
 Java.net      |     | 18.ea.3      | open    |            | 18.ea.3-open
               |     | 18.ea.2      | open    |            | 18.ea.2-open
               |     | 18.ea.1      | open    |            | 18.ea.1-open
               |     | 17.ea.28     | open    |            | 17.ea.28-open
               |     | 17.ea.27     | open    |            | 17.ea.27-open
               |     | 17.ea.26     | open    |            | 17.ea.26-open
               |     | 17.ea.25     | open    |            | 17.ea.25-open
================================================================================

Choose one and install it using the command sdk install java IDENTIFIER, i.e.:

sdk install java 8.0.292-zulu

Boris Azanov
  • 4,408
  • 1
  • 15
  • 28
20

Now, OpenJDK 17 from Oracle supports the Apple M1 chip. The status of the JEP 391 is closed & delivered.

You can download the free, macOS/AArch64 open-source build of the JDK, version 17 from the official website.

Hamza Belmellouki
  • 2,516
  • 1
  • 18
  • 39
  • I tried the OpenJDK18 - now at https://jdk.java.net/18/ The when I navigated in Terminal to the Contents/home/bin folder and typed java --version I got Unable to locate Java Runtime. So it's not the best answer. There must be another part to the jigsaw to get the JRE on a new Mac M1. – JGFMK May 10 '22 at 11:05
  • I just experimented with it now. If you try to execute `java --version` in the `Contents/home/bin` folder, it will execute the system default java cli version(if you already have java in your system). From that folder try to `cd ..` to `Contents/home` and execute `bin/java --version` it should pick up the the JRE version you just installed. – Hamza Belmellouki May 10 '22 at 13:07
  • I ended up using another option jdk-18_macos-aarch64_bin.dmg was what worked for me in the end, per the @Waqas answer. It was a brand new MacBook Pro M1 Max. So no java on the machine beforehand. – JGFMK May 10 '22 at 13:48
15

I am successfully developing Java applications on the new Apple M1 Chip with Azul OpenJDK and NetBeans.

Configuration:

  • zulu16.0.65-ea-jdk16.0.0-ea.24-macos_aarch64
  • NetBeans 12.1 and Maven.
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
  • Hi can I ask if Jenkins is working fine and how did you get the support for maven? Thanks – L m Dec 03 '20 at 18:34
  • 1
    Hi, It is still early days, and there are many open-source packages that do not support the chip. I have not installed Jenkins at present, and the maven packages I have tried so far have presented no issue, no doubt there will be some that will. I am at present like most people exploring only; –  Dec 04 '20 at 21:37
  • Are you using docker? I cannot find an Azul OpenJDK docker image for arm64. – jenglert Feb 10 '21 at 23:09
  • I have not used Docker for the development environment. –  Feb 12 '21 at 02:00
  • Once I install the Azul OpenJDK, how can I run a jnlp file? Seems like it's not possible, since there's no javaws binary? – genevish Mar 04 '21 at 18:28
  • I recommend you investigate the following: Does Azul provide open source versions of Java Web Start (JNLP)? You can download free builds of IcedTea-Web here: https://www.azul.com/downloads/icedtea-web-community/ –  Mar 05 '21 at 22:04
  • Better to work with Python libraries: https://pyspi-toolkit.readthedocs.io/en/latest/faq.html – Adrian Keister Jan 26 '23 at 23:34
15

The latest build for Mac M1's are available now

https://www.oracle.com/java/technologies/downloads/#jdk18-mac

enter image description here

Waqas
  • 3,763
  • 1
  • 30
  • 18
7

I've tried the Azul JDK 8.

I just wanted to say that, while the Azul JDK works natively on Apple M1 and its speed is great, there are still issues. Especially when some Java code needs to call C++ code.

For example, I am a big data developer. And I started using the Azul JDK for my development workflow. But I noticed that certain tests started failing after the switch. For example, when the test writes to a Parquet/Avro file, it fails. I think that is because there are some native things written in C++ for Parquet/Avro, and they are not compiled for M1.

For this specific reason I am forced to use the non-M1 JDK, which is slow. There are no issues there.

Here's an example of the error that I get with Azul that I don't get with non-M1 JDKs:

- convert Base64 JSON back to rpo Avro *** FAILED ***
  org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in stage 10.0 failed 1 times, most recent failure: Lost task 0.0 in stage 10.0 (TID 14, localhost, executor driver): org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Mac and os.arch=aarch64
        at org.xerial.snappy.SnappyLoader.findNativeLibrary(SnappyLoader.java:331)
        at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:171)
        at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:152)
        at org.xerial.snappy.Snappy.<clinit>(Snappy.java:47)
        at org.apache.avro.file.SnappyCodec.compress(SnappyCodec.java:43)
        at org.apache.avro.file.DataFileStream$DataBlock.compressUsing(DataFileStream.java:358)
        at org.apache.avro.file.DataFileWriter.writeBlock(DataFileWriter.java:382)
        at org.apache.avro.file.DataFileWriter.sync(DataFileWriter.java:401)
        at org.apache.avro.file.DataFileWriter.flush(DataFileWriter.java:410)
        at org.apache.avro.file.DataFileWriter.close(DataFileWriter.java:433)
        at org.apache.avro.mapred.AvroOutputFormat$1.close(AvroOutputFormat.java:170)
        at org.apache.spark.internal.io.SparkHadoopWriter.close(SparkHadoopWriter.scala:101)
        at org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsHadoopDataset$1$$anonfun$12$$anonfun$apply$5.apply$mcV$sp(PairRDDFunctions.scala:1145)
        at org.apache.spark.util.Utils$.tryWithSafeFinallyAndFailureCallbacks(Utils.scala:1393)
        at org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsHadoopDataset$1$$anonfun$12.apply(PairRDDFunctions.scala:1145)
        at org.apache.spark.rdd.PairRDDFunctions$$anonfun$saveAsHadoopDataset$1$$anonfun$12.apply(PairRDDFunctions.scala:1125)
        at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:87)
        at org.apache.spark.scheduler.Task.run(Task.scala:108)
        at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:335)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Driver stacktrace:
  at org.apache.spark.scheduler.DAGScheduler.org$apache$spark$scheduler$DAGScheduler$$failJobAndIndependentStages(DAGScheduler.scala:1499)
  at org.apache.spark.scheduler.DAGScheduler$$anonfun$abortStage$1.apply(DAGScheduler.scala:1487)
  at org.apache.spark.scheduler.DAGScheduler$$anonfun$abortStage$1.apply(DAGScheduler.scala:1486)
  at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
  at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
  at org.apache.spark.scheduler.DAGScheduler.abortStage(DAGScheduler.scala:1486)
  at org.apache.spark.scheduler.DAGScheduler$$anonfun$handleTaskSetFailed$1.apply(DAGScheduler.scala:814)
  at org.apache.spark.scheduler.DAGScheduler$$anonfun$handleTaskSetFailed$1.apply(DAGScheduler.scala:814)
  at scala.Option.foreach(Option.scala:257)
  at org.apache.spark.scheduler.DAGScheduler.handleTaskSetFailed(DAGScheduler.scala:814)
  ...
  Cause: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Mac and os.arch=aarch64
  at org.xerial.snappy.SnappyLoader.findNativeLibrary(SnappyLoader.java:331)
  at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:171)
  at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:152)
  at org.xerial.snappy.Snappy.<clinit>(Snappy.java:47)
  at org.apache.avro.file.SnappyCodec.compress(SnappyCodec.java:43)
  at org.apache.avro.file.DataFileStream$DataBlock.compressUsing(DataFileStream.java:358)
  at org.apache.avro.file.DataFileWriter.writeBlock(DataFileWriter.java:382)
  at org.apache.avro.file.DataFileWriter.sync(DataFileWriter.java:401)
  at org.apache.avro.file.DataFileWriter.flush(DataFileWriter.java:410)
  at org.apache.avro.file.DataFileWriter.close(DataFileWriter.java:433)

As you can see, it says: Cause: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Mac and os.arch=aarch64

I googled this issue and they said that the native library is compiled for a later version of Spark, unfortunately.

This frustrated me tremendously, and I want a Windows laptop now, LOL. Running an Intel JDK on the M1 chip can be slow at times, and I don't want that.

Be careful!

Update: They released new versions of their libraries with support for M1, I updated them in the projects and everything works, thank God. Sometimes these "native code errors" manifest themselves with different exceptions and this is additional P.I.T.A. that I have to deal with while my colleagues on windows laptops don't need to deal with it. The errors can be a bit unclear sometimes, but if you see something about native code in the error log, or words like "jna" or "jni", then it's an M1 chip problem.

pavel_orekhov
  • 1,657
  • 2
  • 15
  • 37
  • If a particular lib has native bindings and does not offer an `aarch64` (ARM64) port, you should file a bug report with them. Java developers need to work with the projects in which they are reliant upon to ensure ARM64 support is added, especially if you rely on a volunteer-led project. So I'd argue don't "be careful", but rather "be patient", or better... "be proactive" and send those projects [pull requests](https://github.com/java-native-access/jna/pull/1297), or in your case, [update your library](https://github.com/xerial/snappy-java/commit/ab18bdb45752eeab9dd738b5f83093d27f314e12). – tresf Jun 26 '21 at 16:07
  • And you want me to do this for every single library that has this issue? People should really be careful with using this jdk, because they can waste hours or even days trying to understand why their project isn't getting built and googling the errors that come up from this. It's easier to just use an intel JDK. – pavel_orekhov Aug 17 '21 at 09:51
  • 2
    Yes, it's absolutely the obligation of the community which relies on an open source library to help file bug reports and track what works. That's how open source works. A user or developer finds out what's broken, gets involved, lets the right people know and offer to help. In the specific case of your error a link was provided to a fix. It would benefit others to document this process. Updating this dependency may not be obvious and will differ between projects, but documenting this for others will help progress the community forward. Open source is a crowd-sourced effort. :/ – tresf Aug 17 '21 at 15:52
  • in your specific use-case, a good starting point is to ask a question (e.g. on stack overflow) on how to get your tool working natively with M1 CPUs and cross-link this bug report. Although we may not completely understand the underpinnings of the tools we rely upon, it's very important to set expectations for ourselves and others when it comes to open source libraries. The M1 CPU has exposed many native projects that need updating. Fortunately, most have already been patched, but getting those patches into our projects is a great reason to ask questions on sites like this. :) – tresf Aug 17 '21 at 15:57
  • if someone cares, I got the same problem for `kafka-clients:3.0.0`. I excluded the `snappy` version that comes with that, and upgraded to the latest one - that has M1 arm support – Eugene Jan 20 '22 at 10:15
  • @Eugene yes, I did the same. – pavel_orekhov Jan 20 '22 at 11:58
7

I followed the below steps and I was able to successfully run JDK 16 on a MacBook Air (M1):

  1. Go to "Oracle.com"
  2. Go to ProductsSoftwareJava
  3. Click on "Download Java Now"
  4. Click on "JDK Download"
  5. Select "macOS Installer"
  6. Install JDK
  7. Try with any sample Java program and this should work for you.

I was able to install and successfully run this on my MacBook Air (M1).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Anurag
  • 843
  • 1
  • 9
  • 16
6

Please go to the Azul site and download the .dmg file:

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

This will be placed in a library and once IntelliJ IDEA identifies it, it should be good to run.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Madhav7890
  • 71
  • 1
  • 4
6

You can download the Liberica JDK from:

https://bell-sw.com/pages/downloads/?os=macOS&architecture=ARM

In IntelliJ IDEA for M1, the JetBrains Runtime is also native (ARM64).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Dmitry
  • 61
  • 1
  • 1
  • Example of path for the IDEA jre: `/Users/o_o/Library/Application Support/JetBrains/Toolbox/apps/PyCharm-P/ch-0/211.7628.24/PyCharm.app/Contents/jbr/Contents/Home` – Arnaud P Jul 06 '21 at 12:49
  • For those who need java 8 for ARM: https://bell-sw.com/pages/downloads/#/java-8-lts – ryenus Jul 15 '22 at 13:18
4

It's not just JEP-391.

There is a preview branch, https://github.com/openjdk/jdk-sandbox/tree/JEP-391-branch, one can build JDK 16 early-access (EA) using cross-compilation on Intel Mac or directly on ARM Mac. And it runs fine.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
3

Microsoft and Azul appear to be prime movers on JEP 391 in combination with the Windows port (JEP 388). They have a separate GitHub repository that actually has an EA release for macOS-aarch64.

I am not sure what exact relationship is with the OpenJDK repository.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Peter
  • 31
  • 1
2

Simply use go to Java downloads and in the menu select tab "Java 18" and then tab "macOS". Download the Arm 64 DMG Installer.

You can verify whether it has worked or not by opening up the terminal and typing:

java -version
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Azzam Rar
  • 85
  • 8
-2

Here are steps to install Oracle JDK 8 and run it from Rosetta - https://www.oracle.com/in/java/technologies/javase/javase-jdk8-downloads.html

  • Download the macOS x64 version
  • While attempting to install the package, you will receive a prompt to install Rosetta if it already doesn't exist
  • The rest of the installation steps are as any other package.

You can verify it has worked or not by opening up terminal and typing:

java -version
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Saideep Ullal
  • 221
  • 3
  • 16
  • 3
    JDK 8 is 7 years old at the time of this post. The latest version is JDK 16, which can be downloaded here: https://www.oracle.com/java/technologies/javase-downloads.html#JDK16 The latest LTS version is JDK 11, which can be downloaded here: https://www.oracle.com/java/technologies/javase-jdk11-downloads.html – wto Apr 03 '21 at 11:47
  • The link is broken: *"We found keys. But the page you were looking for is still missing."* – Peter Mortensen Nov 15 '21 at 21:19
  • Note that the original post was asking for a solution that wasn't for x86. That is, the original post wants an ARM JDK. – Kirby Jan 21 '22 at 01:33