Temurin-build: MacOS के लिए बिल्ड जावा टूल्स द्वारा मान्यता प्राप्त नहीं हैं

यह वह फ़ाइल संरचना है जो macOS को उम्मीद है:

➜  jdk1.8.0_121.jdk tree -v -L 3 --charset utf-8
.
└── Contents
    ├── Home
    │   ├── ASSEMBLY_EXCEPTION
    │   ├── COPYRIGHT
    │   ├── LICENSE
    │   ├── README.html
    │   ├── THIRDPARTYLICENSEREADME-JAVAFX.txt
    │   ├── THIRDPARTYLICENSEREADME.txt
    │   ├── THIRD_PARTY_README
    │   ├── bin
    │   ├── db
    │   ├── demo
    │   ├── include
    │   ├── javafx-src.zip
    │   ├── jre
    │   ├── lib
    │   ├── man
    │   ├── release
    │   ├── sample
    │   └── src.zip
    ├── Info.plist
    └── MacOS
        └── libjli.dylib -> ../Home/jre/lib/jli/libjli.dylib

11 directories, 12 files

यह इंस्टॉलर प्रोजेक्ट के लिए एक हो सकता है, लेकिन देखते हैं।

http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html पर उपलब्ध JVMCI JDK का निर्माण करते समय, हम macOS बिल्ड के लिए Contents/Home प्रीफ़िक्स को सुरक्षित रखते हैं। इस मुद्दे में कारण शुरू हुए।

> tree -L 3 /Library/Java/JavaVirtualMachines/labsjdk1.8.0_172-jvmci-0.44
/Library/Java/JavaVirtualMachines/labsjdk1.8.0_172-jvmci-0.44
└── Contents
    ├── Home
    │   ├── COPYRIGHT
    │   ├── LICENSE
    │   ├── README.html
    │   ├── THIRDPARTYLICENSEREADME-JAVAFX.txt
    │   ├── THIRDPARTYLICENSEREADME.txt
    │   ├── bin
    │   ├── db
    │   ├── include
    │   ├── javafx-src.zip
    │   ├── jre
    │   ├── lib
    │   ├── man
    │   ├── release
    │   └── src.zip
    ├── Info.plist
    └── MacOS
        └── libjli.dylib -> ../Home/jre/lib/jli/libjli.dylib

9 directories, 10 files

@johnoliver चूंकि आप नई बिल्ड स्क्रिप्ट के माध्यम से सफलतापूर्वक निर्माण कर रहे हैं - क्या आप इसे देख सकते हैं?

@karianna मुझे वास्तव में ऐसा नहीं लगता है कि हमारे निर्माण इस संरचना में बायनेरिज़ को मंथन कर रहे हैं! हमें शायद मैकोज़ के लिए इंस्टॉलर का यह हिस्सा बनाना चाहिए ताकि उनके पास सही संरचना हो लेकिन हमारे टैरबॉल एक ही आईएमओ बने रहें।

हाँ, मुझे यकीन नहीं है कि इंस्टॉलर या बिल्ड सही संरचना का उत्पादन करता है ...

निर्माण नहीं करता है (और मुझे नहीं लगता कि यह होना चाहिए) हालांकि इस संरचना का उत्पादन करने के लिए इंस्टॉलर को कॉन्फ़िगर किया जा सकता है

मुझे नहीं पता कि क्या मैं किसी ऐसी बात की ओर इशारा करता हूं जिसे हर कोई पहले से जानता है, लेकिन फिर भी...

जब मैं अपने मैक पर जेडीके का निर्माण करता हूं, तो make images build/macosx-x86_64-normal-server-release/images/jdk/ तहत "मानक लिनक्स पेड़" के अतिरिक्त build/macosx-x86_64-normal-server-release/images/jdk-bundle/jdk-11.jdk/ तहत अपेक्षित मैकोज़-अनुकूल निर्देशिका पेड़ बनाता है:

$ tree -L 3 build/macosx-x86_64-normal-server-release/images/jdk-bundle/jdk-11.jdk
build/macosx-x86_64-normal-server-release/images/jdk-bundle/jdk-11.jdk
└── Contents
    ├── Home
    │   ├── bin
    │   ├── conf
    │   ├── demo
    │   ├── include
    │   ├── jmods
    │   ├── legal
    │   ├── lib
    │   ├── man
    │   └── release
    ├── Info.plist
    └── MacOS
        └── libjli.dylib -> ../Home/lib/jli/libjli.dylib
$ tree -L 1 build/macosx-x86_64-normal-server-release/images/jdk
build/macosx-x86_64-normal-server-release/images/jdk
├── bin
├── conf
├── demo
├── include
├── jmods
├── legal
├── lib
├── man
└── release

तो ऐसा लगता है कि इसे बनाते समय किसी अन्य स्रोत निर्देशिका का चयन करके एक "सही" MacOS स्थापना संग्रह बनाया जा सकता है।

साथ ही, देखें https://github.com/AdoptOpenJDK/homebrew-openjdk/issues/9

मैं इससे बिल्कुल भ्रमित हो गया।

मैं या तो उम्मीद कर रहा था

• एक पूर्ण मैक इंस्टॉलर (.plist फ़ाइल सहित)
  या
• एक साधारण टार/संग्रह, जिसे मैं मैन्युअल रूप से ~/java/... etc . के अंतर्गत रखूंगा

वर्तमान में अगर मैं इस प्रारूप में एक फ़ाइल लेता हूं और हमेशा की तरह जीपी पर डबल क्लिक करता हूं। अगर मैं कोशिश करता हूं और खोलता हूं (फाइल एक्सप्लोरर में) तो मुझे टर्मिनल प्रॉम्प्ट मिलता है। और कुछ नहीं। कुछ भी लॉन्च नहीं होता है।

मैं निश्चित रूप से 'जेएनवी' के साथ जेडीके को कॉन्फ़िगर कर सकता हूं या इंटेलिजे के साथ उपयोग कर सकता हूं - बस पिछले सामग्री/होम कूद रहा हूं, लेकिन यह 'अजीब' लगता है। यह न तो एक बात है और न ही अन्य। बस मेरी सोच....

@ Planetf1 ' /usr/libexec/java_home जैसे टूल द्वारा अपेक्षित) आपके JDK को /Library/Java/JavaVirtualMachines के नीचे रखना है और उन्हें .plist फ़ाइल के साथ एक विशिष्ट निर्देशिका संरचना की आवश्यकता है। निर्देशिका संरचना Content/ शुरू होती है, जो फाइंडर द्वारा नहीं दिखाई जाती है, जो शायद आपको भ्रमित कर रही है, लेकिन यह वहां है। यदि आप पैकेज सामग्री पर राइट क्लिक करते हैं और खोलते हैं तो आप इसे फाइंडर में भी देखेंगे।

मुझे लगता है कि https://adoptopenjdk.net/installation.html वास्तव में यह नहीं समझाता है कि JDK को /Library/Java/JavaVirtualMachines तहत स्थानांतरित करना एक अच्छा विचार है। यह अच्छा होगा, तब से आपको अपने $PATH को संशोधित करने की भी आवश्यकता नहीं है और /usr/bin/java बस इसे ढूंढ लेगा।

मुझे लगता है कि अंतिम बिंदु मुख्य है ... oracle jdk install खुद को उस निर्देशिका में कॉपी कर लेगा। उपयोगकर्ता को JDK का 'सिर्फ उपयोग' करने के लिए और कुछ नहीं करने की आवश्यकता है।

डॉक्स पर... कई लोग डॉक्स नहीं पढ़ते हैं, इसलिए कम से कम एक चेतावनी या वास्तविक इंस्टाल में जानकारी या अन्यथा बहुत स्पष्ट मदद करेगा यदि यह स्वचालित नहीं है।

जावा ऐप्स बनाने वाले एक सॉफ्टवेयर इंजीनियर के रूप में मुझे कई जेडीके के साथ काम करने की ज़रूरत है, इसलिए मुझे यह तथ्य पसंद है कि यह डिफ़ॉल्ट रूप से स्थापित नहीं है। मैं macOS पर प्रबंधन करने के लिए 'jenv' का उपयोग करता हूं। यह सिर्फ वर्तमान पैकेजिंग इन दो दृष्टिकोणों के बीच पकड़ा गया लगता है। ध्यान देने योग्य बात यह भी है कि कुछ व्यावसायिक ऐप्स JDK के नए संस्करणों के साथ विफल हो जाएंगे, इसलिए नौसिखिए उपयोगकर्ता के रूप में भी 'डिफ़ॉल्ट' संस्करण को अपडेट करना समस्याग्रस्त हो सकता है

मैं भी एक सॉफ्टवेयर इंजीनियर हूं और मेरे पास कई JDK स्थापित हैं। मैं jenv उपयोग नहीं करता, लेकिन अपने शेल के प्रोफाइल में अपना डिफ़ॉल्ट प्रमुख JDK संस्करण इस तरह सेट करता हूं:

जावा 8 के लिए डिफ़ॉल्ट:

export JAVA_HOME=`/usr/libexec/java_home -v 1.8`

JDK 11 के लिए डिफ़ॉल्ट:

export JAVA_HOME=`/usr/libexec/java_home -v 11`

उदाहरण के लिए यदि आपके पास यह 1.8 सेट है, तो JDK 11 को स्थापित करने से कुछ भी नहीं टूटेगा, क्योंकि आपका डिफ़ॉल्ट JDK प्रमुख संस्करण नहीं बदलेगा।

मेरा मानना ​​​​है कि मूल मुद्दा macOS के लिए वर्तमान एडॉप्टओपेनजेडीके 8u192 और 11.0.1 रिलीज के साथ तय किया गया है।