brew install openjdk En mi caso, después de instalar openjdk con éxito en Mac M1, el comando java aún no funciona. lo arreglo por
brew info openjdkentonces hay un comando como
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.jdkEjecute este comando y el comando Java funcionará
Puede instalar Java JDK usando sdkman (vea sdkman install ):
vim .sdkman/etc/config Establezca sdkman_rosetta2_compatible=false (consulte la configuración de sdkman )
Después de eso, verá una lista de JDK compatibles con M1:
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 ================================================================================ Elija uno e instálelo usando el comando sdk install java IDENTIFIER , es decir:
sdk install java 8.0.292-zulu
Ahora, OpenJDK 17 de Oracle es compatible con el chip Apple M1. El estado de la JEP 391 es cerrado y entregado.
Puede descargar la compilación gratuita de código abierto macOS/AArch64 del JDK, versión 17 desde el sitio web oficial .
Seguí los pasos a continuación y pude ejecutar con éxito JDK 16 en Mac M1:
Pude instalar y ejecutar esto con éxito en mi Mac M1.
Estos son los pasos para instalar Oracle JDK 8 y ejecutarlo desde Rosetta : https://www.oracle.com/in/java/technologies/javase/javase-jdk8-downloads.html
Puede verificar si ha funcionado o no abriendo la terminal y escribiendo:
java -versionUn enfoque de línea de comandos (gracias al equipo de Homebrew y al arduo trabajo de @vladimir-kempik y otros colaboradores de openjdk en la rama JEP-391 )
# Install Homebrew /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" # Install OpenJDK brew install openjdkVerifica que esté instalado:
$(brew --prefix openjdk)/bin/java --versionVerifique que sea para el hardware arm64:
file $(brew --prefix openjdk)/bin/java # /opt/homebrew/opt/openjdk/bin/java: Mach-O 64-bit executable arm64Nota: Para instalar openjdk en todo el sistema, siga las instrucciones en pantalla proporcionadas por Homebrew.
Nota: Al momento de escribir esto, Homebrew puede afirmar que está instalando una versión diferente de OpenJDK en M1. Esto se debe a reglas de empaquetado stable en Homebrew y se solucionará con el tiempo.
He probado el Azul JDK 8.
Solo quería decir que, si bien Azul JDK funciona de forma nativa en Apple M1 y su velocidad es excelente, todavía hay problemas. Especialmente cuando algún código Java necesita llamar al código C++.
Por ejemplo, soy un desarrollador de big data. Y comencé a usar Azul JDK para mi flujo de trabajo de desarrollo. Pero noté que ciertas pruebas comenzaron a fallar después del cambio. Por ejemplo, cuando la prueba escribe en un archivo Parquet / Avro , falla. Creo que se debe a que hay algunas cosas nativas escritas en C++ para Parquet/Avro y no están compiladas para M1.
Por esta razón específica, me veo obligado a usar el JDK que no es M1, que es lento. No hay problemas allí.
Aquí hay un ejemplo del error que recibo con Azul que no obtengo con los JDK que no son M1:
- 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) Como puede ver, dice: Cause: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Mac and os.arch=aarch64
Busqué en Google este problema y dijeron que, lamentablemente, la biblioteca nativa está compilada para una versión posterior de Spark .
Esto me frustró tremendamente, y quiero una computadora portátil con Windows ahora, LOL. Ejecutar un Intel JDK en el chip M1 puede ser lento a veces, y no quiero eso.
¡Ten cuidado!
Actualización: Sacaron nuevas versiones de sus librerías con soporte para M1, las actualicé en los proyectos y todo funciona, gracias a Dios. A veces, estos "errores de código nativo" se manifiestan con diferentes excepciones y este es un PITA adicional con el que tengo que lidiar, mientras que mis colegas en las computadoras portátiles con Windows no necesitan lidiar con eso. Los errores pueden ser un poco confusos a veces, pero si ve algo sobre el código nativo en el registro de errores, o palabras como "jna" o "jni", entonces es un problema del chip M1.
Puede descargar el JDK de Liberica desde:
https://bell-sw.com/pages/downloads/?os=macOS&architecture=ARM
En IntelliJ IDEA para M1, JetBrains Runtime también es nativo (ARM64).
Vaya al sitio de Azul y descargue el archivo .dmg:
https://www.azul.com/downloads/zulu-community/?os=macos&architecture=arm-64-bit&package=jdk
Esto se colocará en una biblioteca y una vez que IntelliJ IDEA lo identifique, debería estar listo para ejecutarse.
Azul ofrece compilaciones macOS ARM de OpenJDK en su sitio web en la sección de Descargas . Sin embargo, aún no los he probado, pero Azul ha sido desarrollador de JDK durante mucho tiempo.
Una vez que descomprime el JDK de Azul, tiene que hurgar en su interior hasta encontrar el directorio zulu-11.jdk (suponiendo que haya descargado JDK 11), que luego copia en /Library/Java/JavaVirtualMachines .
Estoy desarrollando con éxito aplicaciones Java en el nuevo chip Apple M1 con Azul OpenJDK y NetBeans.
Configuración:
No es solo JEP-391.
Hay una rama de vista previa, https://github.com/openjdk/jdk-sandbox/tree/JEP-391-branch , uno puede construir JDK 16 de acceso temprano (EA) usando compilación cruzada en Intel Mac o directamente en ARM Mac. Y funciona bien.
Microsoft y Azul parecen ser los principales impulsores de JEP 391 en combinación con el puerto de Windows (JEP 388). Tienen un repositorio de GitHub separado que en realidad tiene una versión de EA para macOS-aarch64.
No estoy seguro de cuál es la relación exacta con el repositorio de OpenJDK.
Si.
En esta página: Últimos lanzamientos de AdoptOpenJDK , puede seleccionar 'macOS' en el menú desplegable 'Sistema operativo', y luego en 'Arquitectura', actualmente es solo x64, pero pronto debería haber AArch64 o ARM64 (esos son generalmente los códigos cortos para 64- bit ARM). Posiblemente, ya que Apple sin duda tiene un montón de extensiones integradas en sus diseños M1, y Apple obtiene las suyas propias.
Si, en cambio, deja Sistema operativo en 'cualquiera', notará que aarch64 está allí, y esto lo lleva a una versión de Linux para procesadores ARM. Eso (probablemente) no se ejecutará en macOS en hardware M1, pero eso es el 95% del trabajo ya realizado.
Entonces: aún no está allí, pero tenga en cuenta que los JDK para ARM han estado disponibles durante más de una década, y aunque JDK 15 ha dejado de admitir un montón de combinaciones exóticas de SO/arquitectura (como Solaris ), el desarrollo de ARM siempre se ha mantenido al menos parcialmente relevante (incluso si hasta ahora es principalmente una oferta de licencia comercial de Oracle). Es decir: no debería ser un esfuerzo hercúleo crear una versión de adoptopenjdk que se ejecute en M1 de forma nativa, por lo que, presumiblemente, sucederá. Pero es un esfuerzo de código abierto, así que si estás ansioso, por supuesto, lee y contribuye :)
Apple no ha dado ningún detalle sobre esta arquitectura hasta el 10 de noviembre de 2020, a menos que haya comprado una caja de kit de desarrollo (una Mac Mini con un chip A14, que no es un chip M1, pero supongo que lo suficientemente cerca), y firmado un gran acuerdo de confidencialidad .
Como regla general, los proyectos de código abierto se ejecutarán lo más rápido posible en la dirección opuesta si agita un NDA, por lo que si no le gusta este estado de cosas, no creo que sea prudente quejarse de adoptopenjdk u otros empaquetadores y código abierto. proyectos al respecto :)
Afortunadamente, ahora está fuera y ya no se requiere un NDA. Mi suposición es que la rama ARM del código fuente de OpenJDK + los bits de macOS que ya existen para la versión macOS x64 se pueden combinar con bastante facilidad una vez que alguien familiarizado con el código fuente de OpenJDK tiene un sistema macOS basado en M1 para probarlo. , lo que debería significar que debería haber una versión de adoptopenjdk macos-aarch64 dentro de un mes.
Pero, de código abierto. No les pagaste, no tienes contrato y no te lo deben. Done al esfuerzo o contribuya con una solicitud de extracción si desea que sea más rápido.
ACTUALIZAR: