命令行方法(感谢Homebrew团队以及@vladimir-kempik和其他openjdk JEP-391分支贡献者的辛勤工作)

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

# Install OpenJDK
brew install openjdk

确认安装成功:

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

验证它是arm64硬件:

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

注意:要在系统范围内安装openjdk，请遵循Homebrew提供的屏幕说明。

Azul在其网站的下载部分提供macOS ARM版本的OpenJDK。虽然我还没有尝试过，但Azul一直是JDK的长期开发人员。

一旦你解包了Azul JDK，你必须在它里面翻找，直到你找到zulu-11。jdk目录(假设您已经下载了jdk 11)，然后将其复制到/Library/Java/JavaVirtualMachines。

简单地使用Java下载，在菜单中选择选项卡“Java 18”，然后选项卡“macOS”。下载Arm 64 DMG安装程序。

您可以通过以下方法验证它是否有效 打开终端并输入:

java -version

不仅仅是JEP-391。

有一个预览分支，https://github.com/openjdk/jdk-sandbox/tree/JEP-391-branch，你可以在Intel Mac上或直接在ARM Mac上使用交叉编译构建JDK 16早期访问(EA)。它运行良好。

我尝试过Azul JDK 8。

我只是想说，虽然Azul JDK在Apple M1上原生运行，而且速度非常快，但仍然存在一些问题。特别是当一些Java代码需要调用c++代码时。

例如，我是一名大数据开发人员。我开始使用Azul JDK进行开发工作流程。但是我注意到切换后某些测试开始失败。例如，当测试写入Parquet/Avro文件时，它会失败。我认为这是因为有一些用c++为Parquet/Avro编写的原生东西，而不是为M1编译的。

由于这个特殊的原因，我被迫使用速度较慢的非m1 JDK。没有什么问题。

这里有一个我用Azul得到的错误的例子，我没有得到非m1 jdk:

- 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)

正如你所看到的，它说:Cause: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Mac and os.arch=aarch64

我谷歌了一下这个问题，他们说原生库是为Spark的后续版本编译的，不幸的是。

这让我非常沮丧，我现在想要一台Windows笔记本电脑，哈哈。在M1芯片上运行Intel JDK有时会很慢，我不希望这样。

小心!

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.

Yes.

在这个页面:AdoptOpenJDK最新版本你可以从“操作系统”下拉菜单中选择“macOS”，然后从“架构”下拉菜单中选择“macOS”，它目前只有x64，但很快就会有AArch64或ARM64(这些通常是64位ARM的短代码)。可能吧，因为苹果无疑在他们的M1设计中内置了一堆扩展，苹果也有自己的扩展。

如果你把操作系统设置为“any”，你会注意到aarch64在那里，这让你进入了ARM处理器的Linux发行版。这(可能)不会在M1硬件上的macOS上运行，但这已经完成了95%的工作。

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 :)

直到2020年11月10日，苹果公司还没有给出任何关于这一架构的细节，除非你为它买了一个开发工具包(一个带有A14芯片的Mac Mini，这不是M1芯片，但我猜已经足够接近了)，并签署了一份大的保密协议。

作为一个规则，如果你挥舞着NDA，开源项目就会在相反的方向上尽可能快地运行，所以如果你不喜欢这种状态，我认为向adoptopenjdk或其他打包器和开源项目抱怨是不明智的:)

幸运的是，现在它出来了，不再需要保密协议。我的假设是，一旦熟悉OpenJDK源代码的人有一个基于m1的macOS系统来测试它，就可以很容易地将OpenJDK源代码的ARM分支+ macOS x64版本中已经存在的macOS位结合起来，这应该意味着一个月之内就会有一个adoptopenjdk macOS -aarch64版本。

但是，开源。你没有付钱给他们，你没有合同，他们也不欠你的。如果你想让它走得更快，就捐款或贡献一个拉请求。

更新:

Azul的M1 OpenJDK构建 微软(是的，真的)的GitHub源代码回购，用于AArch64上macOS的早期访问OpenJDK16构建。请注意，微软已经在AArch64的OpenJDK分支(用于基于arm的Windows 10)上工作了一段时间，这可以追溯到:很多艰苦的工作已经完成了。