Temurin-build: توفير تصميمات أصلية لأجهزة Mac المستندة إلى ARM

جلسة WWDC 2020 "نقل تطبيق Mac الخاص بك إلى Apple Silicon": https://developer.apple.com/videos/play/wwdc2020/10214/

سوف تحتاج إلى رؤية منفذ Apple Mac OS X يصل إلى المنبع والحصول على مجموعة مطور

إحدى النقاط المفتوحة هي دعم خط أنابيب العرض المعدني الجديد لشركة Apple. تم إهمال OpenGL في MacOS وأفترض أنه لن يتم دعمه على أجهزة Mac المستندة إلى ARM بعد الآن (يلزم التحقق). نظرًا لأن OpenGL قد تم إهماله بالفعل لبعض الوقت ، فإن OpenJDK سيهتم بذلك من خلال تنفيذ خط أنابيب عرض جديد للمعادن. يمكنك العثور على مزيد من المعلومات في 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 silicon.

ليس من الواضح كيف سيتم التعامل مع Java 8 و 11. حتى لو حصلنا على تعهدات في المنبع لجعل OpenJDK يعمل على أجهزة Mac المستندة إلى ARM ، يجب إعادة نقل كل هذا إذا كان سيتم دعم إصدارات Java 8 و 11 LTS.

لا أعرف كيف يتم التعامل مع هذا لمشاريع مماثلة مثل https://openjdk.java.net/jeps/237. ربما يمكن أن تعطي jerboaa إجابة؟

أود أن أحذر من أن لا التكهن بشأن ذلك في هذه المرحلة. ليس من الواضح ما الذي يأتي من إعلان Mac على ARM من حيث OpenJDK. لذا فإن الحديث عن مصدر خلفي لشيء غير موجود هو أمر مبكر جدًا ؛-)

التحدث عن JEP 237 (دمج منفذ Linux Aarch64 في الخط الرئيسي). في الأصل ، بدأ مشروع منفذ 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: 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؟

"JEP 391: منفذ macOS / AArch64" - http://openjdk.java.net/jeps/391 - مراجع JEP 237 (linux / aarch64) و JEP 388 (Windows on Arm).

مشكلة قاعدة بيانات JDK Bugdatabase: 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 ...: د

تتوفر إصدارات openjdk8 / 11/13 من azul - https://www.azul.com/downloads/zulu-community/؟os=macos&architecture=arm-64-bit&package=jdk

هل ستتوفر نسخة "ثنائية عالمية"؟
أنا أسأل لأنني أستخدم الأداة المساعدة jpackage لتجميع تطبيقي ومن الناحية المثالية يجب أن تكون هناك حزمة واحدة تعمل على x86 و arm macs.
أم سأحتاج إلى إنشاء حزمة ثنائية عالمية يدويًا؟

هل ستتوفر نسخة "ثنائية عالمية"؟
أنا أسأل لأنني أستخدم الأداة المساعدة jpackage لتجميع تطبيقي ومن الناحية المثالية يجب أن تكون هناك حزمة واحدة تعمل على x86 و arm macs.
أم سأحتاج إلى إنشاء حزمة ثنائية عالمية يدويًا؟

أهلا

لست متأكدًا مما إذا كان من الممكن حتى لـ 11+ ، مع الأخذ في الاعتبار نظام الوحدة

هل ستتوفر نسخة "ثنائية عالمية"؟
أنا أسأل لأنني أستخدم الأداة المساعدة jpackage لتجميع تطبيقي ومن الناحية المثالية يجب أن تكون هناك حزمة واحدة تعمل على x86 و arm macs.
أم سأحتاج إلى إنشاء حزمة ثنائية عالمية يدويًا؟

أهلا

لست متأكدًا مما إذا كان من الممكن حتى لـ 11+ ، مع الأخذ في الاعتبار نظام الوحدة

لماذا لا يكون؟ أفترض أنه يمكنك فقط دمج arm و x86 binary and libs في إصدارات عالمية باستخدام الأداة المساعدة lipo .
ليس لدي M1 ولكن يمكنني محاولة بناء Jvm عالمي.

لا تنس تفريغ بعض الوحدات التي تحتوي على ثنائيات (مثل libjvm) ، و lipo ثم إعادة حزم الوحدات.

مرحبًا ، هل هناك أي خارطة طريق عندما ستدعم تبنّي OpenJDK معمارية أبل سيليكون؟ شكرا

هل هناك أي خارطة طريق عندما يدعم اعتماد AcceptOpenJDK بنية التفاح السيليكونية

منفذ ARM لـ Apple Silicon قيد التطوير في OpenJDK ، راجع http://openjdk.java.net/jeps/391. طالما لم يتم الانتهاء من ذلك ، فمن غير المحتمل أن يكون هناك إصدار من تبنّي OpenJDK. نود توفير عمليات الإنشاء الليلية قريبًا ، ولكن لم يتم إعداد وظائف البناء بعد (نرحب بالعلاقات العامة).

إصدارات ARM-64 متاحة بالفعل هنا (Java 8 ، 11 ، 13 ، 16)

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

@ davidgiga1993VladimirKempik سؤال جيد حول ثنائيات عالمية تقوم على JLINK. أفترض أن جميع المكتبات الداخلية لـ JVM يجب أن تكون libs عالمية.

يجب أن يكون هناك تحسين على JVM لتحسين CDS للبحث عن jsa لقوس معين ، وإلا فسيحاولون حاليًا (إذا تم إنشاء ثنائيات عالمية) مشاركة ملف class.jsa واحد ، وهذا سيؤدي إلى تعطيل الأشياء قليلاً.

تعتمد بعض لغات البرمجة الأخرى تمامًا على إصدار JVM الخاص بك وتتوقع أن تبني منك ، على سبيل المثال ، Ballerina.IO - https://github.com/ballerina-platform/ballerina-lang/issues/27585

تم التحديث إلى m1 mac mini الجديد ولا يمكنني تشغيل ملف .jar الذي أستخدمه عادةً. لقد قمت بتثبيت Azul ARM-64 Build لـ 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 -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 ، لن يتم دمجها هذا الشهر.

لا يتوفر لدى OpenJDK إصدار مسبق جاهز لـ Apple Silicon وأعتقد أن الأمر سيستغرق بعض الوقت حتى نفعل ذلك. كما قال VladimirKempik ، لا يبدو أن http://openjdk.java.net/jeps/391 (وهو أساس العمل الجاري في OpenJDK) قد يصل إلى 16 عامًا (مستحق منتصف مارس). لذا يبدو أن موعد 17 (من المقرر تقديمه في منتصف سبتمبر) هو الأكثر احتمالًا. Backports هي قصة مختلفة تمامًا. تمتلك Azul تصميمات من Zulu جاهزة لـ Apple Silicon والتي ، على حد علمي ، تستند إلى التصحيحات المخصصة التي طوروها.

نعم ، هذا صحيح ، لدى Azul تصميمات Zulu الجاهزة لـ Apple Silicon. ويسعدنا التحقيق في المساعدة هنا. فقط دعني اعرف.

ppetrosh شكرا جزيلا ، لطيف جدا. نحن في الأساس ننتظر ظهور فرع عام في OpenJDK. هل يوجد بالفعل واحد؟ لقد رأيت فقط أنه تم اقتراح JEP.

تم دمج JEP-391 في jdk17

الآن يمكن للجميع بناء 17ea لأجهزة macarm

هيا بنا نذهب.

• [x] تأكد من أنه يمكن تجميعها باستخدام openjdk-build.
• [x] تكييف نصوص مزرعة البناء في openjdk-build (قيد التقدم)
• [x] تحديد وظائف خطوط الأنابيب (مسودة العلاقات العامة: 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 شكرًا على الإبلاغ ، العلاقات العامة لإصلاحها هنا: https://github.com/AdoptOpenJDK/openjdk-build/pull/2573

devLotto هل يمكنك تأكيد أن هذا تم إصلاحه الآن من