Android बिल्ड में Java वर्शन

चाहे आपका सोर्स कोड Java, Kotlin या दोनों में लिखा गया हो, आपको अपने बिल्ड के लिए जेडीके या Java लैंग्वेज का वर्शन कई जगहों पर चुनना होगा.

शब्दावली

Java डेवलपमेंट किट (जेडीके)

Java डेवलपमेंट किट (जेडीके) में ये शामिल हैं:

• टूल, जैसे कि कंपाइलर, प्रोफ़ाइलर, और आर्काइव क्रिएटर. इनका इस्तेमाल, आपके ऐप्लिकेशन को बनाने के लिए, बिल्ड के दौरान बैकग्राउंड में किया जाता है.
• लाइब्रेरी, जिनमें ऐसे एपीआई शामिल होते हैं जिन्हें आपके Kotlin या Java सोर्स कोड से कॉल किया जा सकता है. ध्यान दें कि Android पर सभी फ़ंक्शन उपलब्ध नहीं होते.
• Java वर्चुअल मशीन (जेवीएम), एक इंटरप्रेटर जो एक्ज़ीक्यूट करता है Java ऐप्लिकेशन को. Android Studio IDE और Gradle बिल्ड टूल को चलाने के लिए, जेवीएम का इस्तेमाल किया जाता है. Android डिवाइसों या एम्युलेटर पर, जेवीएम का इस्तेमाल नहीं किया जाता.

JetBrains Runtime (JBR)

JetBrains Runtime (JBR) एक बेहतर जेडीके है, जो Android Studio के साथ डिस्ट्रिब्यूट किया जाता है. इसमें Studio और JetBrains के अन्य प्रॉडक्ट में इस्तेमाल के लिए कई ऑप्टिमाइज़ेशन शामिल हैं. हालांकि, इसका इस्तेमाल अन्य Java ऐप्लिकेशन को चलाने के लिए भी किया जा सकता है.

Android Studio को चलाने के लिए, जेडीके कैसे चुनें?

हमारा सुझाव है कि Android Studio को चलाने के लिए, JBR का इस्तेमाल करें. इसे Android Studio के साथ डिप्लॉय किया जाता है और इसका इस्तेमाल Android Studio की टेस्टिंग के लिए किया जाता है. इसमें Android Studio के बेहतर इस्तेमाल के लिए, कई सुधार शामिल हैं. यह पक्का करने के लिए, STUDIO_JDK एनवायरमेंट वैरिएबल सेट न करें.

Android Studio के स्टार्टअप स्क्रिप्ट, जेवीएम को इस क्रम में ढूंढते हैं:

1. STUDIO_JDK एनवायरमेंट वैरिएबल
2. studio.jdk डायरेक्ट्री (Android Studio के डिस्ट्रिब्यूशन में)
3. jbr डायरेक्ट्री (JetBrains Runtime), Android Studio के डिस्ट्रिब्यूशन में. सुझाई गई.
4. JDK_HOME एनवायरमेंट वैरिएबल
5. JAVA_HOME एनवायरमेंट वैरिएबल
6. PATH एनवायरमेंट वैरिएबल में, java एक्ज़ीक्यूटेबल

मैं यह कैसे चुनूं कि मेरे Gradle बिल्ड को कौनसा जेडीके चलाता है?

अगर Android Studio में मौजूद बटन का इस्तेमाल करके Gradle चलाया जाता है, तो Gradle को चलाने के लिए, Android Studio की सेटिंग में सेट किए गए जेडीके का इस्तेमाल किया जाता है. अगर Android Studio के अंदर या बाहर, किसी टर्मिनल में Gradle चलाया जाता है, तो JAVA_HOME एनवायरमेंट वैरिएबल (अगर सेट है) यह तय करता है कि Gradle स्क्रिप्ट को कौनसा जेडीके चलाता है. अगर JAVA_HOME सेट नहीं है, तो यह आपके PATH एनवायरमेंट वैरिएबल पर, java कमांड का इस्तेमाल करता है.

सबसे सटीक नतीजे पाने के लिए, पक्का करें कि आपने अपना JAVA_HOME एनवायरमेंट वैरिएबल सेट किया हो. साथ ही, Android Studio में Gradle जेडीके कॉन्फ़िगरेशन को उसी जेडीके पर सेट किया हो.

बिल्ड को रन करते समय, Gradle एक प्रोसेस बनाता है. इसे डीमन कहा जाता है. इसका इस्तेमाल, असल बिल्ड को पूरा करने के लिए किया जाता है. इस प्रोसेस को फिर से इस्तेमाल किया जा सकता है, बशर्ते कि बिल्ड में एक ही जेडीके और Gradle वर्शन का इस्तेमाल किया जा रहा हो. डीमन को फिर से इस्तेमाल करने से, नया जेवीएम शुरू करने और बिल्ड सिस्टम को शुरू करने में लगने वाला समय कम हो जाता है.

अगर अलग-अलग जेडीके या Gradle वर्शन के साथ बिल्ड शुरू किए जाते हैं, तो ज़्यादा डीमन बनाए जाते हैं. इससे ज़्यादा सीपीयू और मेमोरी का इस्तेमाल होता है.

Android Studio में Gradle जेडीके कॉन्फ़िगरेशन

मौजूदा प्रोजेक्ट के Gradle जेडीके कॉन्फ़िगरेशन में बदलाव करने के लिए, फ़ाइल (macOS पर Android Studio) > सेटिंग > बिल्ड, एक्ज़ीक्यूशन, डिप्लॉयमेंट > बिल्ड टूल > Gradle पर जाकर, Gradle की सेटिंग खोलें. Gradle जेडीके ड्रॉप-डाउन में, चुनने के लिए ये विकल्प होते हैं:

• मैक्रो, जैसे कि JAVA_HOME और GRADLE_LOCAL_JAVA_HOME
• vendor-version फ़ॉर्मैट में, jbr-17 जैसे जेडीके टेबल की एंट्री. ये एंट्री, Android कॉन्फ़िगरेशन फ़ाइलों में सेव होती हैं
• जेडीके डाउनलोड करना
• कोई खास जेडीके जोड़ना
• ऑपरेटिंग सिस्टम की डिफ़ॉल्ट जेडीके इंस्टॉलेशन डायरेक्ट्री से, स्थानीय तौर पर पता लगाए गए जेडीके

चुना गया विकल्प, प्रोजेक्ट की .idea/gradle.xml फ़ाइल में मौजूद gradleJvm विकल्प में सेव होता है. साथ ही, Android Studio से शुरू होने पर, Gradle को चलाने के लिए इसके जेडीके पाथ रिज़ॉल्यूशन का इस्तेमाल किया जाता है.

मैक्रो की मदद से, प्रोजेक्ट के जेडीके पाथ को डाइनैमिक तरीके से चुना जा सकता है:

• JAVA_HOME: इसी नाम के एनवायरमेंट वैरिएबल का इस्तेमाल करता है
• GRADLE_LOCAL_JAVA_HOME: .gradle/config.properties फ़ाइल में मौजूद java.home प्रॉपर्टी का इस्तेमाल करता है. यह डिफ़ॉल्ट रूप से JetBrains Runtime पर सेट होती है.

चुने गए जेडीके का इस्तेमाल, Gradle बिल्ड को रन करने और बिल्ड स्क्रिप्ट और सोर्स कोड में बदलाव करते समय, जेडीके एपीआई रेफ़रंस को हल करने के लिए किया जाता है. ध्यान दें कि तय किया गया compileSdk, आपके सोर्स कोड में बदलाव करने और उसे बनाने के दौरान, उपलब्ध होने वाले Java सिंबल को और सीमित कर देगा.

Gradle बिल्ड में इस्तेमाल किए जाने वाले प्लगिन के जेडीके वर्शन से ज़्यादा या उसके बराबर वाला जेडीके वर्शन चुनें. Android Gradle प्लगिन (एजीपी) के लिए, ज़रूरी कम से कम जेडीके वर्शन का पता लगाने के लिए, रिलीज़ नोट में दी गई कंपैटिबिलिटी टेबल देखें.

उदाहरण के लिए, Android Gradle प्लगिन के 8.x वर्शन के लिए, जेडीके 17 की ज़रूरत होती है. अगर Gradle बिल्ड को जेडीके के पुराने वर्शन के साथ चलाने की कोशिश की जाती है, तो यह इस तरह का मैसेज दिखाता है:

An exception occurred applying plugin request [id: 'com.android.application']
> Failed to apply plugin 'com.android.internal.application'.
   > Android Gradle plugin requires Java 17 to run. You are currently using Java 11.
      Your current JDK is located in /usr/local/buildtools/java/jdk
      You can try some of the following options:
       - changing the IDE settings.
       - changing the JAVA_HOME environment variable.
       - changing `org.gradle.java.home` in `gradle.properties`.

मैं अपने Java या Kotlin सोर्स कोड में, Java के किन एपीआई का इस्तेमाल कर सकता/सकती हूं?

Android ऐप्लिकेशन, जेडीके में तय किए गए कुछ एपीआई का इस्तेमाल कर सकता है. हालांकि, सभी एपीआई का इस्तेमाल नहीं किया जा सकता. Android SDK, उपलब्ध एपीआई के तौर पर, Java लाइब्रेरी के कई फ़ंक्शन के लागू करने के तरीके तय करता है. compileSdk प्रॉपर्टी यह तय करती है कि Kotlin या Java सोर्स कोड को कंपाइल करते समय, Android SDK के किस वर्शन का इस्तेमाल करना है.

android {
    ...
    compileSdk = 36
}

android {
    ...
    compileSdk 36
}

Android के हर वर्शन के लिए, जेडीके का कोई खास वर्शन और उसके उपलब्ध Java एपीआई का सबसेट काम करता है. अगर किसी ऐसे compileSdk में मौजूद Java एपीआई का इस्तेमाल किया जाता है जो तय किए गए minSdk में उपलब्ध नहीं है, तो हो सकता है कि Android के पुराने वर्शन में, एपीआई का इस्तेमाल किया जा सके. इसे डीसुगरिंग के तौर पर जाना जाता है. काम करने वाले एपीआई के लिए, डीसुगरिंग की मदद से उपलब्ध Java 11 और इसके बाद के वर्शन के एपीआई देखें.

इस टेबल का इस्तेमाल करके, यह पता लगाएं कि हर Android API के साथ Java का कौनसा वर्शन काम करता है. साथ ही, यह भी पता लगाएं कि Java के कौनसे एपीआई उपलब्ध हैं.

मेरे Java सोर्स कोड को कौनसा जेडीके कंपाइल करता है?

Java टूलचेन जेडीके में, Java कंपाइलर शामिल होता है. इसका इस्तेमाल, Java के किसी भी सोर्स कोड को कंपाइल करने के लिए किया जाता है. यह जेडीके, बिल्ड के दौरान javadoc और यूनिट टेस्ट भी चलाता है.

टूलचेन, डिफ़ॉल्ट रूप से Gradle को चलाने के लिए इस्तेमाल किए गए जेडीके पर सेट होता है. अगर डिफ़ॉल्ट का इस्तेमाल किया जाता है और अलग-अलग मशीनों पर बिल्ड चलाया जाता है (उदाहरण के लिए, आपकी लोकल मशीन और कोई अलग कंटीन्यूअस इंटिग्रेशन सर्वर), तो अलग-अलग जेडीके वर्शन का इस्तेमाल करने पर, आपके बिल्ड के नतीजे अलग-अलग हो सकते हैं.

ज़्यादा सटीक बिल्ड बनाने के लिए, Java टूलचेन का कोई वर्शन साफ़ तौर पर तय किया जा सकता है. इसे तय करने पर:

• बिल्ड को रन करने वाले सिस्टम पर, कंपैटिबल जेडीके ढूंढता है.
  • अगर कोई कंपैटिबल जेडीके मौजूद नहीं है (और टूलचेन रिज़ॉल्वर तय किया गया है), तो उसे डाउनलोड करता है.
• सोर्स कोड से कॉल करने के लिए, टूलचेन Java एपीआई को दिखाता है.
• Java लैंग्वेज के वर्शन का इस्तेमाल करके, Java सोर्स को कंपाइल करता है.
• sourceCompatibility और targetCompatibility के लिए डिफ़ॉल्ट वैल्यू देता है.

हमारा सुझाव है कि Java टूलचेन को हमेशा तय करें. साथ ही, यह पक्का करें कि तय किया गया जेडीके इंस्टॉल हो या अपने बिल्ड में टूलचेन रिज़ॉल्वर जोड़ें.

सोर्स कोड, Java, Kotlin या दोनों में लिखा गया हो, टूलचेन तय किया जा सकता है. अपने मॉड्यूल की build.gradle(.kts) फ़ाइल के टॉप लेवल पर, टूलचेन तय करें.

Java टूलचेन का वर्शन इस तरह तय करें:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

यह तब काम करता है, जब आपका सोर्स Kotlin, Java या दोनों का मिक्स हो.

टूलचेन जेडीके का वर्शन, Gradle को चलाने के लिए इस्तेमाल किए गए जेडीके के वर्शन के बराबर हो सकता है. हालांकि, ध्यान रखें कि दोनों के मकसद अलग-अलग होते हैं.

मैं अपने Java सोर्स कोड में, Java लैंग्वेज के सोर्स की किन सुविधाओं का इस्तेमाल कर सकता/सकती हूं?

sourceCompatibility प्रॉपर्टी यह तय करती है कि Java सोर्स को कंपाइल करते समय, Java लैंग्वेज की कौनसी सुविधाएं उपलब्ध हैं. इससे Kotlin सोर्स पर कोई असर नहीं पड़ता.

अपने मॉड्यूल की build.gradle(.kts) फ़ाइल में, sourceCompatibility को इस तरह तय करें:

android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
    }
}

android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
    }
}

अगर इसे तय नहीं किया जाता है, तो यह प्रॉपर्टी डिफ़ॉल्ट रूप से Java टूलचेन वर्शन पर सेट होती है. अगर Java टूलचेन का इस्तेमाल नहीं किया जा रहा है, तो यह डिफ़ॉल्ट रूप से Android Gradle प्लगिन (उदाहरण के लिए, Java 8 या इसके बाद का वर्शन) की ओर से चुने गए वर्शन पर सेट होती है.

Kotlin या Java सोर्स को कंपाइल करते समय, Java की किन बाइनरी सुविधाओं का इस्तेमाल किया जा सकता है?

targetCompatibility प्रॉपर्टी, कंपाइल किए गए Java और Kotlin सोर्स के लिए बाइटकोड जनरेट करते समय, इस्तेमाल किए गए Java क्लास-फ़ॉर्मैट के वर्शन को तय करती है.

Kotlin की कुछ सुविधाएं, Java की उन सुविधाओं के जोड़े जाने से पहले से मौजूद थीं. Kotlin के शुरुआती कंपाइलर को, Kotlin की उन सुविधाओं को दिखाने के लिए अपना तरीका बनाना पड़ा. इनमें से कुछ सुविधाएं बाद में Java में जोड़ी गईं. targetCompatibility के बाद के लेवल के साथ, Kotlin कंपाइलर सीधे Java की सुविधा का इस्तेमाल कर सकता है. इससे परफ़ॉर्मेंस बेहतर हो सकती है.

Android के अलग-अलग वर्शन के साथ, Java के अलग-अलग वर्शन काम करते हैं. `targetCompatibility` को बढ़ाकर, Java की अन्य सुविधाओं का फ़ायदा लिया जा सकता है. हालांकि, इसके लिए आपको `minimum Android SDK version` को भी बढ़ाना पड़ सकता है, ताकि यह पक्का किया जा सके कि सुविधा उपलब्ध है.

ध्यान दें कि targetCompatibility, sourceCompatibility से ज़्यादा या उसके बराबर होना चाहिए. आम तौर पर, sourceCompatibility और targetCompatibility के लिए एक ही वैल्यू का इस्तेमाल किया जाना चाहिए. इन्हें इस तरह सेट किया जा सकता है:

android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }
}

android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
        targetCompatibility JavaVersion.VERSION_17
    }
}

अगर Kotlin का वर्शन 2.2 से कम है, तो आपको kotlinOptions भी सेट करना होगा:

android {
    kotlinOptions {
        jvmTarget = "17"
    }
}

android {
    kotlinOptions {
        jvmTarget = "17"
    }
}

अगर इन प्रॉपर्टी को तय नहीं किया जाता है, तो ये डिफ़ॉल्ट रूप से Java टूलचेन के वर्शन पर सेट होती हैं. अगर Java टूलचेन का इस्तेमाल नहीं किया जा रहा है, तो डिफ़ॉल्ट वैल्यू अलग-अलग हो सकती हैं और इससे बिल्ड में समस्याएं आ सकती हैं. इसलिए, हमारा सुझाव है कि इन वैल्यू को हमेशा साफ़ तौर पर तय करें या Java टूलचेन का इस्तेमाल करें.