Temurin-build: Предоставлять собственные сборки для компьютеров Mac на базе ARM

Сессия WWDC 2020 «Перенос приложения Mac на Apple Silicon»: https://developer.apple.com/videos/play/wwdc2020/10214/

Нужно будет увидеть порт Apple Mac OS X и получить комплект разработчика.

Один из открытых моментов - поддержка нового конвейера рендеринга Metal от Apple. OpenGL устарел в MacOS, и я предполагаю, что он больше не будет поддерживаться на компьютерах Mac на базе ARM (требуется проверка). Поскольку OpenGL уже давно устарел, OpenJDK позаботится об этом, реализовав новый конвейер рендеринга для Metal. Вы можете найти больше информации в JEP 382 и на странице проекта Lanai . Сборку для раннего доступа можно найти здесь . Неизвестно, какая часть проекта Lanai должна быть переработана при ориентации на ARM.

Неясно, как будут обрабатываться Java 8 и 11. Даже если мы получим коммиты в апстриме, чтобы OpenJDK работал на компьютерах Mac на базе ARM, все это должно быть перенесено обратно, если будут поддерживаться версии Java 8 и 11 LTS.

Я не знаю, как это делается для подобных проектов, таких как https://openjdk.java.net/jeps/237. Может @jerboaa ответит? Рядом с этим Microsoft опубликовала статью о работе над OpenJDK для Win / ARM . Репо можно найти здесь . Может быть, @karianna скажет, как это будет

Зарегистрируйте OpenGL, цитируя https://developer.apple.com/documentation/xcode/porting_your_macos_apps_to_apple_silicon :

OpenGL устарел, но доступен на микросхеме Apple.

Неясно, как будут обрабатываться Java 8 и 11. Даже если мы получим коммиты в апстриме, чтобы OpenJDK работал на компьютерах Mac на базе ARM, все это должно быть перенесено обратно, если будут поддерживаться версии Java 8 и 11 LTS.

Я не знаю, как это делается для подобных проектов, таких как https://openjdk.java.net/jeps/237. Может @jerboaa ответит?

Я хотел бы предостеречь, чтобы не размышлять об этом на данном этапе. Непонятно, что выйдет из этого Mac с анонсом ARM с точки зрения OpenJDK. Так что говорить о бэкпорте чего-то, чего не существует, слишком рано ;-)

Говоря о JEP 237 (интеграция порта Linux Aarch64 в mainline). Первоначально проект порта Aarch64 был задуман как проект OpenJDK. Вот где произошло развитие. Это было задолго до того, как случился JEP 237. В какой-то момент его предложили включить в основную ветку. Вот что такое JEP 237. Он был нацелен на JDK 9. Таким образом, OpenJDK 9+ имеет Aarch64 в качестве поддерживаемой архитектуры (в Linux) в основной линии. Код OpenJDK 8u для Aarch64 все еще поддерживается в репозитории проекта портов Aarch64 [1]. То есть поддержки Aarch64 в OpenJDK 8u нет в основной версии OpenJDK 8u. Хотя раньше предлагалось интегрировать его в основную версию OpenJDK 8u, и есть интерес интегрировать его. Вопрос в том, когда это произойдет.

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

@jerboaa THX за этот отзыв. Я не хочу строить догадки. Я просто собираю информацию, чтобы понять общую картину :)

добавление https://github.com/AdoptOpenJDK/openjdk-support/issues/146

Тема в списке рассылки JavaFX Dev: https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-July/026949.html

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

Проблема SWT для предоставления универсальных двоичных файлов: https://bugs.eclipse.org/bugs/show_bug.cgi?id=565690

«JEP 391: порт macOS / AArch64» - http://openjdk.java.net/jeps/391 - ссылается на JEP 237 (linux / aarch64) и JEP 388 (Windows on Arm).

Проблема с базой данных ошибок JDK: https://bugs.openjdk.java.net/browse/JDK-8253795

Предварительный просмотр ... https://github.com/microsoft/openjdk-aarch64/releases/tag/16-ea%2B10-macos

Если бы кто-то сказал мне 5 лет назад, что Microsoft предоставляет первую сборку Java 16 для компьютеров Mac на базе ARM ...: D

Сборки openjdk8 / 11/13 доступны на сайте azul - https://www.azul.com/downloads/zulu-community/?os=macos&architecture=arm-64-bit&package=jdk

Будет ли доступна «универсальная бинарная» версия?
Я спрашиваю, потому что я использую утилиту jpackage для объединения моего приложения, и в идеале должен быть один пакет, который работает на x86 и arm Mac.
Или мне нужно будет вручную создать универсальный бинарный пакет?

Будет ли доступна «универсальная бинарная» версия?
Я спрашиваю, потому что я использую утилиту jpackage для объединения моего приложения, и в идеале должен быть один пакет, который работает на x86 и arm Mac.
Или мне нужно будет вручную создать универсальный бинарный пакет?

Привет

Я не уверен, что это вообще возможно для 11+, учитывая модульную систему

Будет ли доступна «универсальная бинарная» версия?
Я спрашиваю, потому что я использую утилиту jpackage для объединения моего приложения, и в идеале должен быть один пакет, который работает на x86 и arm Mac.
Или мне нужно будет вручную создать универсальный бинарный пакет?

Привет

Я не уверен, что это вообще возможно для 11+, учитывая модульную систему

Почему не должно быть? Я предполагаю, что вы можете просто объединить бинарный файл arm, x86 и библиотеки в универсальные версии с помощью утилиты lipo .
У меня нет M1, но я мог бы попробовать создать универсальный jvm.

не забудьте распаковать некоторые модули, в которых есть двоичные файлы (например, libjvm), lipo, а затем перепаковать модули.

Привет, есть ли какой-нибудь план, когда AdoptOpenJDK будет поддерживать кремниевую архитектуру Apple? Спасибо

есть ли дорожная карта, когда AdoptOpenJDK будет поддерживать архитектуру кремния Apple?

Порт ARM для Apple Silicon находится в разработке в OpenJDK, см. Http://openjdk.java.net/jeps/391. Пока он не закончен, выпуск AdoptOpenJDK вряд ли будет. Мы хотели бы предоставить ночные сборки в ближайшее время, но рабочие места сборки еще не созданы (PR приветствуются).

Сборки ARM-64 уже доступны здесь (Java 8, 11, 13, 16)

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

@ davidgiga1993 @VladimirKempik хороший вопрос об универсальных двоичных файлах на основе jlink. Я предполагаю, что все внутренние библиотеки JVM должны быть универсальными библиотеками.

необходимо усовершенствовать JVM, чтобы улучшить CDS для поиска jsa для конкретной арки, иначе в настоящее время (если созданы универсальные двоичные файлы) они попытаются совместно использовать один файл classes.jsa, и это немного притормозит.

Некоторые другие языки программирования основаны именно на вашей версии JVM и ожидают от вас сборки, например Ballerina.IO - https://github.com/ballerina-platform/ballerina-lang/issues/27585

Обновлен до нового m1 mac mini и не может запустить файл .jar, который я обычно использую. Я установил Azul ARM-64 Build for 11. Есть какие-нибудь рекомендации / идеи?

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)

Версия 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)

вы пытаетесь использовать кешированные библиотеки openjfx mac_intel с mac_arm java.

пока нет openjfx для mac_arm java.

Есть ли график для порта OpenJFX в Apple Arm?

Проблема зонтика для поддержки Apple Silicon для OpenJFX: https://bugs.openjdk.java.net/browse/JDK-8257222.

он уже вышел два месяца назад, но у разных производителей.
Что касается JEP-391, он не будет интегрирован в этом месяце.

AdoptOpenJDK не имеет готовой предварительной версии для Apple Silicon, и я предполагаю, что это займет некоторое время, пока мы ее не сделаем. Как сказал @VladimirKempik , не похоже, что http://openjdk.java.net/jeps/391 (который является основой работы, проводимой в OpenJDK) может составить 16 (срок до середины марта). Так что 17 (середина сентября) выглядит более вероятным. Бэкпорты - это совсем другая история. У Azul есть сборки Zulu, готовые для Apple Silicon , которые, насколько я понимаю, основаны на пользовательских патчах, которые они разработали.

Да, верно, у Azul есть сборки Zulu, готовые для Apple Silicon. И мы рады рассмотреть возможность оказания здесь помощи. Просто дай мне знать.

@ppetrosh Большое спасибо, очень любезно. Мы в основном ждем появления общедоступной ветки в OpenJDK. Уже есть? Я только видел, что был предложен JEP.

JEP-391 был интегрирован в jdk17

теперь каждый может собрать 17шт для макарма

Давайте идти.

• [x] Убедитесь, что его можно скомпилировать с помощью openjdk-build.
• [x] Адаптировать скрипты сборки фермы в openjdk-build (в процессе)
• [x] Определите задания конвейера (черновик PR: https://github.com/AdoptOpenJDK/ci-jenkins-pipelines/pull/113)
• [x] Организуйте машины сборки (https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/2092)
• [x] Организуйте тестовые машины (https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/2093)
• [] Убедитесь, что наше тестирование работает (https://github.com/AdoptOpenJDK/openjdk-tests/issues/2421)

Тестирование выполняется, хотя будет проделана работа, чтобы пройти все тесты. Если закрыть его как https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk/job/jdk-mac-arm64-hotspot/, он теперь будет запускаться на регулярной основе.

@sxa Вы уверены, что артефакты содержат двоичные файлы arm64? file java показывает мне Mach-O 64-bit executable x86_64 для сборки 35.

Хм, это немного беспокоит, позвольте мне еще раз проверить

@devLotto спасибо за сообщение, PR, чтобы исправить здесь: https://github.com/AdoptOpenJDK/openjdk-build/pull/2573

@devLotto, можете ли вы подтвердить, что теперь это исправлено с вашей стороны? Спасибо