Temurin-build: Fournir des versions natives pour les Mac basés sur ARM

Session WWDC 2020 "Portez votre application Mac vers Apple Silicon": https://developer.apple.com/videos/play/wwdc2020/10214/

Aura besoin de voir le port Mac OS X d'Apple arriver en amont et d'obtenir un kit de développement

Un point ouvert est la prise en charge du nouveau pipeline de rendu Metal d'Apple. OpenGL est obsolète dans MacOS et je suppose qu'il ne sera plus pris en charge sur les Mac basés sur ARM (une vérification est nécessaire). Étant donné qu'OpenGL est déjà obsolète depuis un certain temps, OpenJDK s'occupera de cela en implémentant un nouveau pipeline de rendu pour Metal. Vous pouvez trouver plus d'informations dans le JEP 382 et la page du projet Lanai . Une version d'accès anticipé peut être trouvée ici . La quantité de projet Lanai qui doit être refactorisée lors du ciblage d'ARM est inconnue.

On ne sait pas comment Java 8 et 11 seront gérés. Même si nous obtenons des commits en amont pour qu'OpenJDK fonctionne sur des Mac basés sur ARM, tout cela doit être rétroporté si les versions Java 8 et 11 LTS seront prises en charge.

Je ne sais pas comment cela est géré pour des projets similaires comme https://openjdk.java.net/jeps/237. Peut-être que @jerboaa peut donner une réponse ? À côté de cela, Microsoft a publié un article sur le travail sur OpenJDK pour Win/ARM . Le dépôt peut être trouvé ici . Peut-être que @karianna peut dire comment cela sera géré pour le

Regading OpenGL, en citant https://developer.apple.com/documentation/xcode/porting_your_macos_apps_to_apple_silicon :

OpenGL est obsolète, mais est disponible sur le silicium d'Apple.

On ne sait pas comment Java 8 et 11 seront gérés. Même si nous obtenons des commits en amont pour qu'OpenJDK fonctionne sur des Mac basés sur ARM, tout cela doit être rétroporté si les versions Java 8 et 11 LTS seront prises en charge.

Je ne sais pas comment cela est géré pour des projets similaires comme https://openjdk.java.net/jeps/237. Peut-être que @jerboaa peut donner une réponse ?

Je voudrais mettre en garde de ne pas spéculer à ce stade à ce stade. On ne sait pas ce qu'il advient de cette annonce Mac on ARM en termes d'OpenJDK. Donc parler d'un backport de quelque chose qui n'existe pas est bien trop tôt ;-)

Parlant pour JEP 237 (intégration du port Linux Aarch64 dans la ligne principale). A l'origine, le projet de port Aarch64 a été conçu comme un projet OpenJDK. C'est là que le développement s'est produit. C'était bien avant le JEP 237. À un moment donné, il a été proposé pour inclusion dans la ligne principale. C'est ce qu'est le JEP 237. Il ciblait JDK 9. Ainsi, OpenJDK 9+ a Aarch64 comme architecture prise en charge (sur Linux) dans la ligne principale. Le code OpenJDK 8u pour Aarch64 est toujours conservé dans le référentiel d'un projet de ports Aarch64[1]. C'est-à-dire que la prise en charge d'Aarch64 dans OpenJDK 8u n'est pas dans la ligne principale OpenJDK 8u. Cependant, il a déjà été proposé de l'intégrer dans la ligne principale OpenJDK 8u et il y a un intérêt à l'intégrer. La question est de savoir quand cela arrivera.

[1] http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/

@jerboaa THX pour ces commentaires. Je ne veux pas spéculer. Je collecte juste des informations pour comprendre la situation dans son ensemble :)

ajout de https://github.com/AdoptOpenJDK/openjdk-support/issues/146

Discussion dans la liste de diffusion JavaFX Dev : https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-July/026949.html

http://openjdk.java.net/jeps/8251280

Problème SWT pour fournir des binaires universels : https://bugs.eclipse.org/bugs/show_bug.cgi?id=565690

"JEP 391 : macOS/AArch64 Port" - http://openjdk.java.net/jeps/391 - références JEP 237 (linux/aarch64) et JEP 388 (Windows on Arm).

Problème de base de données de bogues JDK : https://bugs.openjdk.java.net/browse/JDK-8253795

Aperçu rapide .. https://github.com/microsoft/openjdk-aarch64/releases/tag/16-ea%2B10-macos

Si quelqu'un m'avait dit il y a 5 ans que Microsoft fournit la première version Java 16 pour les Mac basés sur ARM... :D

Les versions openjdk8/11/13 sont disponibles sur azul - https://www.azul.com/downloads/zulu-community/?os=macos&architecture=arm-64-bit&package=jdk

Une version "binaire universel" sera-t-elle disponible ?
Je pose la question car j'utilise l'utilitaire jpackage pour regrouper mon application et, idéalement, il devrait y avoir un ensemble qui s'exécute sur x86 et arm macs.
Ou dois-je créer manuellement un package binaire universel ?

Une version "binaire universel" sera-t-elle disponible ?
Je pose la question car j'utilise l'utilitaire jpackage pour regrouper mon application et, idéalement, il devrait y avoir un ensemble qui s'exécute sur x86 et arm macs.
Ou dois-je créer manuellement un package binaire universel ?

Bonjour

Je ne sais pas si c'est même possible pour 11+, compte tenu du système de modules

Une version "binaire universel" sera-t-elle disponible ?
Je pose la question car j'utilise l'utilitaire jpackage pour regrouper mon application et, idéalement, il devrait y avoir un ensemble qui s'exécute sur x86 et arm macs.
Ou dois-je créer manuellement un package binaire universel ?

Bonjour

Je ne sais pas si c'est même possible pour 11+, compte tenu du système de modules

Pourquoi ne devrait-il pas être? Je suppose que vous pouvez simplement fusionner les binaires arm et x86 et les bibliothèques en versions universelles à l'aide de l'utilitaire lipo .
Je n'ai pas de M1 mais je pourrais essayer de construire un jvm universel.

n'oubliez pas de décompresser certains modules qui ont des binaires (comme libjvm), lipo, puis de remballer les modules.

Bonjour, existe-t-il une feuille de route lorsque AdoptOpenJDK prendra en charge l'architecture silicium d'Apple ? Merci

existe-t-il une feuille de route lorsque AdoptOpenJDK prendra en charge l'architecture silicium d'Apple

Le port ARM pour Apple Silicon est en cours de développement chez OpenJDK, voir http://openjdk.java.net/jeps/391. Tant qu'il n'est pas terminé, il est peu probable qu'il y ait une version d'AdoptOpenJDK. Nous aimerions fournir des constructions nocturnes bientôt, mais les tâches de construction n'ont pas encore été configurées (les relations publiques sont les bienvenues).

Les builds ARM-64 sont déjà disponibles ici (Java 8, 11, 13, 16)

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

@davidgiga1993 @VladimirKempik bonne question sur les binaires universels basés sur jlink. Je suppose que toutes les bibliothèques internes de la JVM doivent être des bibliothèques universelles.

il devrait y avoir une amélioration de JVM pour améliorer CDS pour rechercher jsa pour une arch spécifique, sinon actuellement (si des binaires universels sont créés), ils essaieront de partager un fichier classes.jsa, ce qui freinera un peu les choses.

Certains autres langages de programmation sont basés exactement sur votre version JVM et s'attendent à être construits à partir de vous, par exemple, Ballerina.IO - https://github.com/ballerina-platform/ballerina-lang/issues/27585

Mis à jour vers le nouveau mac mini m1 et ne peut pas exécuter un fichier .jar que j'utilise généralement. J'ai installé Azul ARM-64 Build for 11. Des conseils/idées ?

java -jar /Users/austin/Downloads/updatetool-gui-mac-1.0.0.jar 
Loading library prism_es2 from resource failed: java.lang.UnsatisfiedLinkError: /Users/austin/.openjfx/cache/13/libprism_es2.dylib: dlopen(/Users/austin/.openjfx/cache/13/libprism_es2.dylib, 1): no suitable image found.  Did find:
    /Users/austin/.openjfx/cache/13/libprism_es2.dylib: mach-o, but wrong architecture
    /Users/austin/.openjfx/cache/13/libprism_es2.dylib: mach-o, but wrong architecture
java.lang.UnsatisfiedLinkError: /Users/austin/.openjfx/cache/13/libprism_es2.dylib: dlopen(/Users/austin/.openjfx/cache/13/libprism_es2.dylib, 1): no suitable image found.  Did find:
    /Users/austin/.openjfx/cache/13/libprism_es2.dylib: mach-o, but wrong architecture
    /Users/austin/.openjfx/cache/13/libprism_es2.dylib: mach-o, but wrong architecture
    at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
    at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
    at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
    at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
    at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
    at java.base/java.lang.Runtime.load0(Runtime.java:768)
    at java.base/java.lang.System.load(System.java:1837)
    at com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:214)
    at com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:194)
    at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:135)
    at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:53)
    at com.sun.prism.es2.ES2Pipeline.lambda$static$0(ES2Pipeline.java:68)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at com.sun.prism.es2.ES2Pipeline.<clinit>(ES2Pipeline.java:50)
    at java.base/java.lang.Class.forName0(Native Method)
    at java.base/java.lang.Class.forName(Class.java:315)
    at com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
    at java.base/java.lang.Thread.run(Thread.java:834)
Loading library prism_sw from resource failed: java.lang.UnsatisfiedLinkError: /Users/austin/.openjfx/cache/13/libprism_sw.dylib: dlopen(/Users/austin/.openjfx/cache/13/libprism_sw.dylib, 1): no suitable image found.  Did find:
    /Users/austin/.openjfx/cache/13/libprism_sw.dylib: mach-o, but wrong architecture
    /Users/austin/.openjfx/cache/13/libprism_sw.dylib: mach-o, but wrong architecture
java.lang.UnsatisfiedLinkError: /Users/austin/.openjfx/cache/13/libprism_sw.dylib: dlopen(/Users/austin/.openjfx/cache/13/libprism_sw.dylib, 1): no suitable image found.  Did find:
    /Users/austin/.openjfx/cache/13/libprism_sw.dylib: mach-o, but wrong architecture
    /Users/austin/.openjfx/cache/13/libprism_sw.dylib: mach-o, but wrong architecture
    at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
    at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
    at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
    at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
    at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
    at java.base/java.lang.Runtime.load0(Runtime.java:768)
    at java.base/java.lang.System.load(System.java:1837)
    at com.sun.glass.utils.NativeLibLoader.installLibraryFromResource(NativeLibLoader.java:214)
    at com.sun.glass.utils.NativeLibLoader.loadLibraryFromResource(NativeLibLoader.java:194)
    at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:135)
    at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:53)
    at com.sun.prism.sw.SWPipeline.lambda$static$0(SWPipeline.java:42)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at com.sun.prism.sw.SWPipeline.<clinit>(SWPipeline.java:41)
    at java.base/java.lang.Class.forName0(Native Method)
    at java.base/java.lang.Class.forName(Class.java:315)
    at com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:218)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
    at java.base/java.lang.Thread.run(Thread.java:834)
Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
    at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
    at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244)
    at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260)
    at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
    at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
    at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
    at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
    at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
    at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
    ... 1 more
Exception in thread "main" java.lang.RuntimeException: No toolkit found
    at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272)
    at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
    at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
    at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
    at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
    at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
    at java.base/java.lang.Thread.run(Thread.java:834)

Version Java :

java -version
openjdk version "11.0.9.1" 2020-11-04 LTS
OpenJDK Runtime Environment Zulu11.43+1021-CA (build 11.0.9.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.43+1021-CA (build 11.0.9.1+1-LTS, mixed mode)

vous essayez d'utiliser les bibliothèques openjfx mac_intel mises en cache avec mac_arm java.

il n'y a pas encore d'openjfx pour mac_arm java.

Existe-t-il un calendrier pour un port OpenJFX vers Apple Arm ?

Problème de parapluie pour la prise en charge d'Apple Silicon pour OpenJFX : https://bugs.openjdk.java.net/browse/JDK-8257222.

il est déjà sorti depuis deux mois, chez un autre fournisseur.
A partir du JEP-391, il ne sera pas intégré ce mois-ci.

AdoptOpenJDK n'a pas de pré-version prête pour Apple Silicon et je suppose que cela va prendre un certain temps jusqu'à ce que nous le fassions. Comme l'a dit @VladimirKempik , il ne semble pas que http://openjdk.java.net/jeps/391 (qui est la base du travail en cours chez OpenJDK) pourrait en faire 16 (à prévoir mi-mars). Donc 17 (échéance mi-septembre) semble plus probable. Les rétroportages sont une histoire totalement différente. Azul a des versions de Zulu prêtes pour Apple Silicon qui, à ma connaissance, sont basées sur des correctifs personnalisés qu'ils ont développés.

Oui, c'est vrai, Azul a les versions de Zulu prêtes pour Apple Silicon. Et nous sommes heureux d'enquêter sur l'aide ici. Faites-le moi savoir.

@ppetrosh Merci beaucoup, très gentil. Nous attendons essentiellement qu'une branche publique apparaisse dans OpenJDK. Y en a-t-il déjà un ? J'ai seulement vu que le JEP a été proposé.

JEP-391 a été intégré dans jdk17

maintenant tout le monde peut construire 17ea pour macarm

Allons-y.

• [x] Assurez-vous qu'il peut être compilé avec openjdk-build.
• [x] Adapter les scripts de la ferme de build dans openjdk-build (en cours)
• [x] Définir les tâches de pipeline (projet de RP : https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/113)
• [x] Organiser les machines de construction (https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/2092)
• [x] Organiser les machines de test (https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/2093)
• [ ] Assurez-vous que nos tests fonctionnent (https://github.com/AdoptOpenJDK/openjdk-tests/issues/2421)

Les tests s'exécutent bien que des travaux soient effectués pour le faire passer toutes les suites. Fermer ceci en tant que https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk/job/jdk-mac-arm64-hotspot/ s'exécutera désormais régulièrement.

@sxa Êtes-vous sûr que les artefacts contiennent des binaires arm64? file java montre Mach-O 64-bit executable x86_64 pour moi pour la build 35.

Hmm c'est un peu inquiétant, permettez-moi de vérifier à nouveau

@devLotto merci pour le signalement, PR à corriger ici : https://github.com/AdoptOpenJDK/openjdk-build/pull/2573

@devLotto pouvez-vous confirmer que cela est maintenant corrigé de votre côté ? Merci