Temurin-build: एआरएम आधारित मैक के लिए देशी बिल्ड प्रदान करें

WWDC 2020 सत्र "अपने मैक ऐप को ऐप्पल सिलिकॉन में पोर्ट करें": https://developer.apple.com/videos/play/wwdc2020/10214/

Apple के Mac OS X पोर्ट को अपस्ट्रीम में आने और डेवलपर किट प्राप्त करने की आवश्यकता होगी

एक खुला बिंदु Apple की नई धातु रेंडरिंग पाइपलाइन के लिए समर्थन है। ओपनजीएल मैकोज़ में बहिष्कृत है और मुझे लगता है कि इसे अब एआरएम आधारित मैक पर समर्थित नहीं किया जाएगा (सत्यापन की आवश्यकता है)। चूंकि ओपनजीएल कुछ समय के लिए पहले से ही बहिष्कृत है, ओपनजेडीके धातु के लिए एक नई प्रतिपादन पाइपलाइन को लागू करके इसका ख्याल रखेगा। आप जेईपी ३८२ और लानई परियोजना पृष्ठ में अधिक जानकारी प्राप्त कर सकते हैं। एक अर्ली एक्सेस बिल्ड यहां पाया जा सकता

यह स्पष्ट नहीं है कि Java 8 और 11 को कैसे हैंडल किया जाएगा। यहां तक ​​कि अगर हम ओपनजेडीके को एआरएम आधारित मैक पर काम करने के लिए अपस्ट्रीम के लिए प्रतिबद्ध करेंगे तो यह सब वापस पोर्ट किया जाना चाहिए यदि जावा 8 और 11 एलटीएस संस्करणों का समर्थन किया जाएगा।

मुझे नहीं पता कि https://openjdk.java.net/jeps/237 जैसी समान परियोजनाओं के लिए इसे कैसे संभाला जाता है @jerboaa कोई जवाब दे सकता है? इसके आगे माइक्रोसॉफ्ट ने विन/एआरएम के लिए ओपनजेडीके पर काम के बारे में एक यहां पाया जा सकता @karianna कह सकती हैं कि

ओपनजीएल के बारे में बताते हुए https://developer.apple.com/documentation/xcode/porting_your_macos_apps_to_apple_silicon :

ओपनजीएल पदावनत है, लेकिन ऐप्पल सिलिकॉन पर उपलब्ध है।

यह स्पष्ट नहीं है कि Java 8 और 11 को कैसे हैंडल किया जाएगा। यहां तक ​​कि अगर हम ओपनजेडीके को एआरएम आधारित मैक पर काम करने के लिए अपस्ट्रीम के लिए प्रतिबद्ध करेंगे तो यह सब वापस पोर्ट किया जाना चाहिए यदि जावा 8 और 11 एलटीएस संस्करणों का समर्थन किया जाएगा।

मुझे नहीं पता कि https://openjdk.java.net/jeps/237 जैसी समान परियोजनाओं के लिए इसे कैसे संभाला जाता है @jerboaa कोई जवाब दे सकता है?

मैं इस स्तर पर इस पर अटकलें नहीं लगाने के लिए सावधान करना चाहता हूं। ओपनजेडीके के संदर्भ में एआरएम घोषणा पर इस मैक का क्या आता है यह स्पष्ट नहीं है। तो किसी ऐसी चीज के बैकपोर्ट की बात करना जो अस्तित्व में नहीं है, बहुत जल्दी है ;-)

JEP 237 (लिनक्स Aarch64 पोर्ट इंटीग्रेशन इन मेनलाइन) के लिए बोलते हुए। मूल रूप से आर्क 64 पोर्ट प्रोजेक्ट को ओपनजेडीके प्रोजेक्ट के रूप में स्थापित किया गया था। यहीं विकास हुआ। यह जेईपी 237 के घटित होने से काफी पहले था। किसी समय इसे मेनलाइन में शामिल करने का प्रस्ताव मिला। जेईपी 237 यही है। इसने JDK 9 को लक्षित किया। इस प्रकार, OpenJDK 9+ में मेनलाइन में समर्थित आर्किटेक्चर (लिनक्स पर) के रूप में Aarch64 है। Aarch64 के लिए OpenJDK 8u कोड अभी भी Aarch64 पोर्ट्स प्रोजेक्ट के रिपॉजिटरी [1] में बनाए रखा गया है। अर्थात्, OpenJDK 8u में Aarch64 समर्थन मेनलाइन OpenJDK 8u में नहीं है। हालाँकि, इसे पहले मेनलाइन OpenJDK 8u में एकीकृत करने का प्रस्ताव दिया गया है और इसे एकीकृत करने के लिए रुचि है। सवाल यह है कि ऐसा कब होगा।

[१] 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?id=565690

"JEP 391: macOS/AArch64 पोर्ट" - http://openjdk.java.net/jeps/391 - संदर्भ JEP 237 (linux/aarch64) और JEP 388 (विंडोज ऑन आर्म)।

JDK बगडेटाबेस समस्या: https://bugs.openjdk.java.net/browse/JDK-8253795

चुपके पूर्वावलोकन.. https://github.com/microsoft/openjdk-aarch64/releases/tag/16-ea%2B10-macos

अगर किसी ने मुझे 5 साल पहले बताया होगा कि माइक्रोसॉफ्ट एआरएम आधारित मैक के लिए पहला जावा 16 बिल्ड प्रदान करता है ...: डी

openjdk8/11/13 बिल्ड अज़ुल से उपलब्ध हैं - https://www.azul.com/downloads/zulu-community/?os=macos&architecture=arm-64-bit&package=jdk

क्या कोई "सार्वभौमिक बाइनरी" संस्करण उपलब्ध होगा?
मैं पूछ रहा हूं क्योंकि मैं अपने ऐप को बंडल करने के लिए jpackage उपयोगिता का उपयोग करता हूं और आदर्श रूप से एक बंडल होना चाहिए जो x86 और आर्म मैक पर चलता हो।
या क्या मुझे मैन्युअल रूप से एक सार्वभौमिक बाइनरी पैकेज बनाने की आवश्यकता होगी?

क्या कोई "सार्वभौमिक बाइनरी" संस्करण उपलब्ध होगा?
मैं पूछ रहा हूं क्योंकि मैं अपने ऐप को बंडल करने के लिए jpackage उपयोगिता का उपयोग करता हूं और आदर्श रूप से एक बंडल होना चाहिए जो x86 और आर्म मैक पर चलता हो।
या क्या मुझे मैन्युअल रूप से एक सार्वभौमिक बाइनरी पैकेज बनाने की आवश्यकता होगी?

नमस्ते

मुझे यकीन नहीं है कि यह 11+ के लिए भी संभव है, मॉड्यूल सिस्टम को देखते हुए

क्या कोई "सार्वभौमिक बाइनरी" संस्करण उपलब्ध होगा?
मैं पूछ रहा हूं क्योंकि मैं अपने ऐप को बंडल करने के लिए jpackage उपयोगिता का उपयोग करता हूं और आदर्श रूप से एक बंडल होना चाहिए जो x86 और आर्म मैक पर चलता हो।
या क्या मुझे मैन्युअल रूप से एक सार्वभौमिक बाइनरी पैकेज बनाने की आवश्यकता होगी?

नमस्ते

मुझे यकीन नहीं है कि यह 11+ के लिए भी संभव है, मॉड्यूल सिस्टम को देखते हुए

यह क्यों नहीं होना चाहिए? मुझे लगता है कि आप lipo उपयोगिता का उपयोग करके केवल हाथ और x86 बाइनरी और libs को सार्वभौमिक संस्करणों में विलय कर सकते हैं।
मेरे पास M1 नहीं है, लेकिन मैं एक यूनिवर्सल jvm बनाने की कोशिश कर सकता हूं।

कुछ मॉड्यूल को अनपैक करना न भूलें जिनमें बायनेरिज़ (जैसे libjvm), लिपो हैं और फिर मॉड्यूल को दोबारा पैक करें।

नमस्ते, क्या कोई रोडमैप है जब एडॉप्टओपेनजेडीके सेब सिलिकॉन वास्तुकला का समर्थन करेगा? धन्यवाद

क्या कोई रोडमैप है जब एडॉप्टओपेनजेडीके सेब सिलिकॉन आर्किटेक्चर का समर्थन करेगा?

ऐप्पल सिलिकॉन के लिए एआरएम पोर्ट ओपनजेडीके में विकास में है, http://openjdk.java.net/jeps/391 देखें। जब तक यह समाप्त नहीं हो जाता है, तब तक इसकी संभावना नहीं है कि एडॉप्टओपेनजेडीके से रिलीज होने जा रहा है। हम नाइटली-बिल्ड जल्द-ईश प्रदान करना चाहते हैं, लेकिन बिल्ड जॉब्स अभी तक स्थापित नहीं किए गए हैं (पीआर का स्वागत है)।

एआरएम -64 बिल्ड यहां पहले से ही उपलब्ध हैं (जावा 8, 11, 13, 16)

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

@ davidgiga1993 @VladimirKempik jlink पर आधारित सार्वभौमिक बायनेरिज़ के बारे में अच्छा सवाल है। मुझे लगता है कि जेवीएम के सभी आंतरिक पुस्तकालय सार्वभौमिक libs होने चाहिए।

विशिष्ट आर्क के लिए जेएसए की तलाश के लिए सीडीएस में सुधार के लिए जेवीएम में सुधार होना चाहिए, अन्यथा वर्तमान में (यदि सार्वभौमिक बायनेरिज़ बनाए गए हैं) तो वे एक क्लास.जेएसए फ़ाइल साझा करने का प्रयास करेंगे, और इससे चीजें थोड़ी टूट जाएंगी।

कुछ अन्य प्रोग्रामिंग भाषाएं बिल्कुल आपके JVM संस्करण पर आधारित हैं और आपसे निर्माण की अपेक्षा करती हैं, उदाहरण के लिए, Ballerina.IO - https://github.com/ballerina-platform/ballerina-lang/issues/27585

नए m1 मैक मिनी में अपडेट किया गया और मैं आमतौर पर उपयोग की जाने वाली .jar फ़ाइल नहीं चला सकता। मैंने अज़ुल एआरएम-६४ बिल्ड फॉर ११ स्थापित किया। कोई मार्गदर्शन/विचार?

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)

आप mac_arm java के साथ कैश्ड openjfx mac_intel पुस्तकालयों का उपयोग करने का प्रयास कर रहे हैं।

mac_arm java के लिए अभी तक कोई openjfx नहीं है।

क्या ऐप्पल आर्म में ओपनजेएफएक्स पोर्ट के लिए कोई समयरेखा है?

OpenJFX के लिए Apple सिलिकॉन सपोर्ट के लिए अम्ब्रेला इश्यू: https://bugs.openjdk.java.net/browse/JDK-8257222।

यह पहले से ही दो महीने के लिए अलग-अलग विक्रेता से बाहर है।
JEP-391 के अनुसार, इसे इस महीने एकीकृत नहीं किया जाएगा।

एडॉप्टओपेनजेडीके में ऐप्पल सिलिकॉन के लिए प्री-रिलीज़ तैयार नहीं है और मुझे लगता है कि जब तक हम ऐसा नहीं करेंगे तब तक इसमें कुछ समय लगेगा। जैसा कि @VladimirKempik ने कहा, यह http://openjdk.java.net/jeps/391 (जो ओपनजेडीके में हो रहे काम का आधार है) की तरह नहीं दिखता 16 (मार्च के मध्य में) हो सकता है। तो 17 (सितंबर के मध्य में) अधिक संभावना दिखता है। बैकपोर्ट एक पूरी तरह से अलग कहानी है। अज़ुल ने ऐप्पल सिलिकॉन के लिए तैयार ज़ुलु का निर्माण किया है , जहां तक ​​​​मैं समझता हूं, उनके द्वारा विकसित कस्टम पैच के आधार पर।

हाँ, यह सही है, अज़ुल के पास Apple Silicon के लिए Zulu के बिल्ड तैयार हैं। और हमें यहां मदद करने की जांच करने में खुशी हो रही है। बस मुझे पता है।

@ppetrosh बहुत बहुत धन्यवाद, बहुत दयालु। हम मूल रूप से OpenJDK में एक सार्वजनिक शाखा के प्रकट होने की प्रतीक्षा कर रहे हैं। क्या पहले से ही एक है? मैंने केवल यह देखा है कि जेईपी प्रस्तावित किया गया है।

JEP-391 को jdk17 . में एकीकृत किया गया था

अब हर कोई macarm के लिए 17ea बना सकता है

चलो जाते रहे।

• [x] सुनिश्चित करें कि इसे openjdk-build के साथ संकलित किया जा सकता है।
• [x] ओपनजेडके-बिल्ड (प्रगति में) में बिल्ड फार्म स्क्रिप्ट को अनुकूलित करें
• [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 क्या आप पुष्टि कर सकते हैं कि यह अब आपके अंत में तय हो गया है? धन्यवाद