💚 Bazel को बेहतर बनाने में हमारी मदद करने के लिए, Bazel के उपयोगकर्ताओं के लिए उपलब्ध सर्वे में हिस्सा लें: https://bazel.build/survey 💚

इस पेज का अनुवाद Cloud Translation API से किया गया है.

Java के नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.2 · 8.1 · 8.0 · 7.6 · 7.5

नियम

java_binary
java_import
java_library
java_test
java_package_configuration
java_plugin
java_runtime
java_single_jar
java_toolchain

java_binary

नियम का सोर्स देखें

java_binary(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_env, deploy_manifest_lines, deprecation, env, exec_compatible_with, exec_group_compatible_with, exec_properties, features, javacopts, jvm_flags, launcher, licenses, main_class, neverlink, output_licenses, package_metadata, plugins, resource_strip_prefix, restricted_to, runtime_deps, stamp, tags, target_compatible_with, testonly, toolchains, use_launcher, use_testrunner, visibility)

यह एक Java संग्रह ("jar फ़ाइल") बनाता है. साथ ही, नियम के नाम वाली एक रैपर शेल स्क्रिप्ट भी बनाता है. रैपर शेल स्क्रिप्ट, क्लासपाथ का इस्तेमाल करती है. इसमें कई चीज़ों के साथ-साथ, हर उस लाइब्रेरी के लिए एक jar फ़ाइल शामिल होती है जिस पर बाइनरी निर्भर करती है. रैपर शेल स्क्रिप्ट को चलाते समय, किसी भी खाली न होने वाले JAVABIN एनवायरमेंट वैरिएबल को, Bazel के --java_runtime_version फ़्लैग के ज़रिए तय किए गए वर्शन के मुकाबले प्राथमिकता दी जाएगी.

रैपर स्क्रिप्ट में कई यूनीक फ़्लैग इस्तेमाल किए जा सकते हैं. रैपर के ज़रिए कॉन्फ़िगर किए जा सकने वाले फ़्लैग और एनवायरमेंट वैरिएबल की सूची देखने के लिए, java_stub_template.txt पर जाएं.

इंप्लिसिट आउटपुट टारगेट

name.jar: एक Java संग्रह, जिसमें बाइनरी की डायरेक्ट डिपेंडेंसी से जुड़ी क्लास फ़ाइलें और अन्य रिसॉर्स शामिल होते हैं.
name-src.jar: सोर्स ("सोर्स jar") वाला संग्रह.
name_deploy.jar: डिप्लॉयमेंट के लिए सही Java संग्रह (सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो).
अपने नियम के लिए <name>_deploy.jar टारगेट बनाने पर, एक ऐसी jar फ़ाइल बनती है जिसमें एक मेनिफ़ेस्ट होता है. इसकी मदद से, इसे java -jar कमांड या रैपर स्क्रिप्ट के --singlejar विकल्प के साथ चलाया जा सकता है. java -jar के बजाय, रैपर स्क्रिप्ट का इस्तेमाल करना बेहतर होता है, क्योंकि यह JVM फ़्लैग और नेटिव लाइब्रेरी को लोड करने के विकल्पों को भी पास करती है.

डिप्लॉय किए गए jar में वे सभी क्लास शामिल होती हैं जो किसी क्लास लोडर को मिलती हैं. यह क्लास लोडर, बिटरी के रैपर स्क्रिप्ट से शुरू करके आखिर तक क्लासपथ को खोजता है. इसमें डिपेंडेंसी के लिए ज़रूरी नेटिव लाइब्रेरी भी शामिल होती हैं. ये रनटाइम के दौरान, JVM में अपने-आप लोड हो जाते हैं.

अगर आपके टारगेट में लॉन्चर एट्रिब्यूट की वैल्यू दी गई है, तो _deploy.jar एक सामान्य JAR फ़ाइल के बजाय, एक नेटिव बाइनरी होगी. इसमें लॉन्चर के साथ-साथ, आपके नियम की सभी नेटिव (C++) डिपेंडेंसी शामिल होंगी. ये सभी एक स्टैटिक बाइनरी में लिंक होती हैं. असल jar फ़ाइल के बाइट को उस नेटिव बाइनरी में जोड़ दिया जाएगा. इससे एक बाइनरी ब्लॉब बन जाएगा, जिसमें एक साथ, बाइनरी और Java कोड, दोनों मौजूद होंगे. इस प्रोसेस के बाद बनी jar फ़ाइल को सीधे तौर पर, किसी भी नेटिव बाइनरी की तरह चलाया जा सकता है.
name_deploy-src.jar: यह एक संग्रह है, जिसमें टारगेट के ट्रांसीटिव क्लोज़र से इकट्ठा किए गए सोर्स शामिल होते हैं. ये deploy.jar में मौजूद क्लास से मैच करेंगे. हालांकि, ऐसा उन जगहों पर नहीं होगा जहां जार का कोई सोर्स जार नहीं है.

सोर्स फ़ाइल के नाम का इस्तेमाल करना अच्छा होता है. यह ऐप्लिकेशन का मुख्य एंट्री पॉइंट होता है. इसमें एक्सटेंशन नहीं होता. उदाहरण के लिए, अगर आपके एंट्री पॉइंट का नाम Main.java है, तो आपका नाम Main हो सकता है.

java_binary नियम में deps एट्रिब्यूट का इस्तेमाल, srcs के बिना नहीं किया जा सकता. ऐसे नियम में, runtime_deps से दी गई main_class वैल्यू का इस्तेमाल करना ज़रूरी है.

यहां दिए गए कोड स्निपेट में, एक सामान्य गलती के बारे में बताया गया है:


java_binary(
    name = "DontDoThis",
    srcs = [
        ...,
        "GeneratedJavaFile.java",  # a generated .java file
    ],
    deps = [":generating_rule",],  # rule that generates that file
)

इसके बजाय, यह तरीका अपनाएं:


java_binary(
    name = "DoThisInstead",
    srcs = [
        ...,
        ":generating_rule",
    ],
)

तर्क

विशेषताएं
`name`	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं.
`srcs`	लेबल की सूची; डिफ़ॉल्ट `[]` है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. इस एट्रिब्यूट की वैल्यू सबमिट करना ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, कुछ मामलों में ऐसा नहीं होता. इन अपवादों के बारे में यहां बताया गया है. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई `.java` फ़ाइलों के लिए, आम तौर पर फ़ाइल के नाम के बजाय, जनरेट करने वाले नियम का नाम यहां डालने का सुझाव दिया जाता है. इससे न सिर्फ़ नियम को पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को ज़्यादा बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम का `outs`. आपको `deps` में जनरेट करने वाला नियम नहीं डालना चाहिए, क्योंकि यह कोई काम का नहीं है. `.srcjar` टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर कोई नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए किया जाता है. यह आर्ग्युमेंट ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर किसी क्लास की जानकारी देता है या आपने `runtime_deps` आर्ग्युमेंट दिया है, तो यह ज़रूरी नहीं है.
`data`	लेबल की सूची; डिफ़ॉल्ट `[]` है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. `data` के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों से तय किए गए सामान्य एट्रिब्यूट पर जाएं.
`resources`	लेबल की सूची; डिफ़ॉल्ट `[]` है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट हुई सामान्य `.class` फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह लेआउट, "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री के पोते के तौर पर होता है. अगर वह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई वैकल्पिक डायरेक्ट्री तय की जा सकती है.
`add_exports`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी को दिए गए `module` या `package` को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग से जुड़ा है.
`add_opens`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी को, दिए गए `module` या `package` को रिफ़्लेक्टिव तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग से जुड़ा है.
`bootclasspath`	लेबल; डिफ़ॉल्ट `None` है प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
`classpath_resources`	लेबल की सूची; डिफ़ॉल्ट `[]` है इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई दूसरा विकल्प न हो) उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का एक ही मकसद है, तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना जिनके लिए ज़रूरी है कि उनके रिसॉर्स, क्लासपाथ पर `"myconfig.xml"` के तौर पर मिलें. नेमस्पेस के टकराव की आशंका की वजह से, इसका इस्तेमाल सिर्फ़ बाइनरी में किया जा सकता है, न कि लाइब्रेरी में.
`create_executable`	बूलियन; डिफ़ॉल्ट तौर पर `True` इस सुविधा के इस्तेमाल पर रोक लगा दी गई है. इसके बजाय, `java_single_jar` का इस्तेमाल करें.
`deploy_env`	लेबल की सूची; डिफ़ॉल्ट `[]` है इस बाइनरी के डिप्लॉयमेंट एनवायरमेंट को दिखाने वाले अन्य `java_binary` टारगेट की सूची. इस एट्रिब्यूट को तब सेट करें, जब कोई ऐसा प्लग इन बनाया जा रहा हो जिसे किसी दूसरे `java_binary` से लोड किया जाएगा. इस एट्रिब्यूट को सेट करने पर, इस बाइनरी के रनटाइम क्लासपाथ (और डिप्लॉय किए गए jar) से उन सभी डिपेंडेंसी को हटा दिया जाता है जो इस बाइनरी और `deploy_env` में बताए गए टारगेट के बीच शेयर की जाती हैं.
`deploy_manifest_lines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` `_deploy.jar` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट में, "वैरिएबल बनाएं" विकल्प का इस्तेमाल करके बदलाव नहीं* किया जा सकता.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस बाइनरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
`jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में जोड़ने के लिए फ़्लैग की सूची. $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से. Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH परिभाषा शामिल होती है, ताकि सभी डिपेंडेंट jar ढूंढे जा सकें. साथ ही, यह सही Java इंटरप्रेटर को भी शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम और उसके बाद `"$@"` होता है, ताकि क्लास के नाम के बाद अन्य आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM के पास पार्स करने के लिए जिन आर्ग्युमेंट का इस्तेमाल करना है उन्हें कमांड लाइन पर क्लास के नाम से पहले तय करना होगा. क्लास का नाम शामिल करने से पहले, `jvm_flags` के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ा जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर* नहीं पड़ता.
`launcher`	लेबल; डिफ़ॉल्ट `None` है JDK में शामिल सामान्य `bin/java` प्रोग्राम के बजाय, अपने Java प्रोग्राम को चलाने के लिए इस्तेमाल किए जाने वाले बाइनरी के बारे में बताएं. टारगेट एक `cc_binary` होना चाहिए. Java Invocation API को लागू करने वाले किसी भी `cc_binary` को इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. इससे जुड़े `--java_launcher` Bazel फ़्लैग का असर सिर्फ़ उन `java_binary` और `java_test` टारगेट पर पड़ता है जिनके लिए `launcher` एट्रिब्यूट की वैल्यू न दी गई है. ध्यान दें कि JDK लॉन्चर या किसी अन्य लॉन्चर का इस्तेमाल करने पर, आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी अलग-अलग तरीके से बनाई जाएंगी: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी को `{name}_nativedeps.so` नाम की शेयर की गई लाइब्रेरी के तौर पर बनाया जाता है. यहां `{name}`, इस java_binary नियम का `name` एट्रिब्यूट है. इस कॉन्फ़िगरेशन में, लिंकर इस्तेमाल न किए गए कोड को नहीं हटाता. अगर किसी दूसरे लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी को `{name}_nativedeps` नाम के बाइनरी में स्टैटिक तौर पर लिंक किया जाता है. यहां `{name}`, इस java_binary नियम का `name` एट्रिब्यूट है. इस मामले में, लिंकर उस कोड को हटा देगा जो उसके हिसाब से, बाइनरी में इस्तेमाल नहीं किया गया है. इसका मतलब है कि सिर्फ़ JNI के ज़रिए ऐक्सेस किया गया कोई भी C++ कोड तब तक लिंक नहीं किया जा सकता, जब तक कि `cc_library` टारगेट में `alwayslink = True` की जानकारी न दी गई हो. डिफ़ॉल्ट JDK लॉन्चर के अलावा किसी दूसरे लॉन्चर का इस्तेमाल करने पर, `*_deploy.jar` आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
`main_class`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, `main()` तरीके वाली क्लास का नाम. अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो उसे `srcs=[...]` सूची की ज़रूरत नहीं होती. इस एट्रिब्यूट की मदद से, किसी ऐसी Java लाइब्रेरी से एक ऐसी एक्सीक्यूटेबल बनाई जा सकती है जिसमें पहले से ही एक या उससे ज़्यादा `main()` तरीके मौजूद हों. इस एट्रिब्यूट की वैल्यू, सोर्स फ़ाइल नहीं, बल्कि क्लास का नाम होती है. क्लास, रनटाइम के दौरान उपलब्ध होनी चाहिए: इसे इस नियम (`srcs` से) से संकलित किया जा सकता है या सीधे या ट्रांज़िशन वाली डिपेंडेंसी (`runtime_deps` या `deps` के ज़रिए) से उपलब्ध कराया जा सकता है. अगर क्लास उपलब्ध नहीं है, तो बाइनरी रनटाइम के दौरान काम नहीं करेगी; बिल्ड के समय कोई जांच नहीं की जाती.
`neverlink`	बूलियन; डिफ़ॉल्ट तौर पर `False`
`plugins`	लेबल की सूची; डिफ़ॉल्ट `[]` है कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में बताए गए हर `java_plugin` को चलाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से प्लग इन भी इनहेरिट हो सकते हैं जो `exported_plugins` का इस्तेमाल करती हैं. प्लग इन से जनरेट किए गए संसाधन, इस नियम के नतीजे के जार में शामिल किए जाएंगे.
`resource_strip_prefix`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` Java रिसॉर्स से हटाने के लिए पाथ प्रीफ़िक्स. अगर यह पाथ प्रीफ़िक्स दिया गया है, तो `resources` एट्रिब्यूट की हर फ़ाइल से इसे हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर यह जानकारी नहीं दी गई है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के उसी लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद सोर्स फ़ाइल, `foo/bar/a.txt` पर मौजूद होगी.
`runtime_deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है ऐसी लाइब्रेरी जिन्हें फ़ाइनल बाइनरी या सिर्फ़ रनटाइम के दौरान टेस्ट करने के लिए उपलब्ध कराया जाता है. सामान्य `deps` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये `deps` के उलट, कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी को यहां सूची में शामिल किया जाना चाहिए. डिपेंडेंसी-ऐनालिसिस टूल को उन टारगेट को अनदेखा करना चाहिए जो `runtime_deps` और `deps`, दोनों में दिखते हैं.
`stamp`	पूर्णांक; डिफ़ॉल्ट वैल्यू `-1` है बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. वैल्यू, इनमें से कोई हो सकती है: `stamp = 1`: बिल्डर की जानकारी को हमेशा बाइनरी में स्टैंप करें. ऐसा `--nostamp` बिल्डर में भी करें. इस सेटिंग का इस्तेमाल नहीं किया जाना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल नहीं किया जा सकता. `stamp = 0`: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे, बिल्ड के नतीजे को कैश मेमोरी में सेव करने की सुविधा मिलती है. `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने की सुविधा, `--[no]stamp` फ़्लैग से कंट्रोल की जाती है. स्टैंप की गई बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
`use_launcher`	बूलियन; डिफ़ॉल्ट तौर पर `True` बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए या नहीं. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो इस टारगेट के लिए लॉन्चर एट्रिब्यूट और उससे जुड़े `--java_launcher` फ़्लैग को अनदेखा कर दिया जाएगा.
`use_testrunner`	बूलियन; डिफ़ॉल्ट तौर पर `False` किसी Java प्रोग्राम के मुख्य एंट्री पॉइंट के तौर पर, टेस्ट रनर (डिफ़ॉल्ट रूप से `com.google.testing.junit.runner.BazelTestRunner`) क्लास का इस्तेमाल करें. साथ ही, टेस्ट रनर को `bazel.test_suite` सिस्टम प्रॉपर्टी की वैल्यू के तौर पर टेस्ट क्लास दें. इसका इस्तेमाल, डिफ़ॉल्ट व्यवहार को बदलने के लिए किया जा सकता है. डिफ़ॉल्ट तौर पर, `java_test` नियमों के लिए टेस्ट रननर का इस्तेमाल किया जाता है और `java_binary` नियमों के लिए इसका इस्तेमाल नहीं किया जाता. ऐसा होने की संभावना कम है. इसका एक इस्तेमाल, `AllTest` उन नियमों के लिए किया जाता है जिन्हें किसी दूसरे नियम से चालू किया जाता है. उदाहरण के लिए, जांच चलाने से पहले डेटाबेस सेट अप करने के लिए. `AllTest` नियम को `java_binary` के तौर पर घोषित किया जाना चाहिए. हालांकि, इसके लिए अब भी टेस्ट रनर को मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करना चाहिए. टेस्ट रनर क्लास के नाम को `main_class` एट्रिब्यूट की मदद से बदला जा सकता है.

java_import

नियम का सोर्स देखें

java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, package_metadata, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)

इस नियम की मदद से, पहले से संकलित .jar फ़ाइलों का इस्तेमाल, java_library और java_binary नियमों के लिए लाइब्रेरी के तौर पर किया जा सकता है.

उदाहरण


    java_import(
        name = "maven_model",
        jars = [
            "maven_model/maven-aether-provider-3.2.3.jar",
            "maven_model/maven-model-3.2.3.jar",
            "maven_model/maven-model-builder-3.2.3.jar",
        ],
    )

तर्क

विशेषताएं
`name`	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. java_library.deps देखें.
`data`	लेबल की सूची; डिफ़ॉल्ट `[]` है रनटाइम के दौरान, इस नियम के लिए ज़रूरी फ़ाइलों की सूची.
`add_exports`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी को दिए गए `module` या `package` को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग से जुड़ा है.
`add_opens`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी को, दिए गए `module` या `package` को रिफ़्लेक्टिव तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग से जुड़ा है.
`constraints`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` Java लाइब्रेरी के तौर पर, इस नियम पर अतिरिक्त पाबंदियां लगाई गई हैं.
`exports`	लेबल की सूची; डिफ़ॉल्ट `[]` है इस नियम के उपयोगकर्ताओं के लिए उपलब्ध कराने के लिए टारगेट. java_library.exports देखें.
`jars`	लेबल की सूची; ज़रूरी है इस टारगेट पर निर्भर Java टारगेट के लिए दी गई JAR फ़ाइलों की सूची.
`neverlink`	बूलियन; डिफ़ॉल्ट तौर पर `False` इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए करें, न कि रनटाइम के दौरान. यह तब काम का होता है, जब रनटाइम एनवायरमेंट, प्रोग्राम को लागू करने के दौरान लाइब्रेरी उपलब्ध कराएगा. इस तरह की लाइब्रेरी के उदाहरणों में, IDE प्लग-इन के लिए IDE एपीआई या स्टैंडर्ड JDK पर चलने वाली किसी भी चीज़ के लिए `tools.jar` शामिल हैं.
`proguard_specs`	लेबल की सूची; डिफ़ॉल्ट `[]` है Proguard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनमें, Proguard के इस्तेमाल के लिए स्पेसिफ़िकेशन के सेट के बारे में बताया जाएगा. अगर इनका इस्तेमाल किया जाता है, तो इन्हें इस लाइब्रेरी के आधार पर किसी भी `android_binary` टारगेट में जोड़ दिया जाएगा. यहां शामिल फ़ाइलों में सिर्फ़ एक जैसे नियम होने चाहिए. जैसे, -dontnote, -dontwarn, assumenosideeffects, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ `android_binary` के proguard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि टॉटोलॉजिकल मर्ज न हों.
`runtime_deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है ऐसी लाइब्रेरी जिन्हें फ़ाइनल बाइनरी या सिर्फ़ रनटाइम के दौरान टेस्ट करने के लिए उपलब्ध कराया जाता है. java_library.runtime_deps देखें.
`srcjar`	लेबल; डिफ़ॉल्ट `None` है ऐसी JAR फ़ाइल जिसमें कंपाइल की गई JAR फ़ाइलों का सोर्स कोड होता है.

java_library

नियम का सोर्स देखें

java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, package_metadata, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)

यह नियम, सोर्स को .jar फ़ाइल में कंपाइल और लिंक करता है.

इंप्लिसिट आउटपुट

libname.jar: क्लास फ़ाइलों वाला Java संग्रह.
libname-src.jar: सोर्स ("सोर्स jar") वाला संग्रह.

तर्क

विशेषताएं
`name`	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है इस लाइब्रेरी से लिंक की जाने वाली लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. `deps` में दिए गए `java_library` नियमों से बनाए गए jar, इस नियम के संकलन के समय के क्लासपाथ पर होंगे. इसके अलावा, उनके `deps`, `runtime_deps`, और `exports` के ट्रांज़िटिव क्लोज़र, रनटाइम क्लासपाथ पर होंगे. इसके उलट, `data` एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल होते हैं, लेकिन ये 'कंपाइल के समय' या 'रनटाइम क्लासपाथ' में शामिल नहीं होते.
`srcs`	लेबल की सूची; डिफ़ॉल्ट `[]` है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. इस एट्रिब्यूट की वैल्यू सबमिट करना ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, कुछ मामलों में ऐसा नहीं होता. इन अपवादों के बारे में यहां बताया गया है. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई `.java` फ़ाइलों के लिए, आम तौर पर फ़ाइल के नाम के बजाय, जनरेट करने वाले नियम का नाम यहां डालने का सुझाव दिया जाता है. इससे न सिर्फ़ नियम को पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को ज़्यादा बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम का `outs`. आपको `deps` में जनरेट करने वाला नियम नहीं डालना चाहिए, क्योंकि यह कोई काम का नहीं है. `.srcjar` टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर कोई नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए किया जाता है. `.properties` टाइप की सोर्स फ़ाइलों को संसाधन माना जाता है. ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद होने पर, बाकी सभी फ़ाइलों को अनदेखा कर दिया जाता है. ऐसा न करने पर, गड़बड़ी का मैसेज दिखता है. `runtime_deps` आर्ग्युमेंट के अलावा, इस आर्ग्युमेंट की ज़रूरत हमेशा होती है.
`data`	लेबल की सूची; डिफ़ॉल्ट `[]` है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. `data` के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. `java_library` बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं डालता. अगर `data` फ़ाइलें जनरेट की गई फ़ाइलें हैं, तो Bazel उन्हें जनरेट करता है. इस `java_library` पर निर्भर करने वाले किसी जांच को बनाते समय, Bazel `data` फ़ाइलों को रनफ़ाइल एरिया में कॉपी करता है या लिंक करता है.
`resources`	लेबल की सूची; डिफ़ॉल्ट `[]` है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट हुई सामान्य `.class` फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह लेआउट, "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री के पोते के तौर पर होता है. अगर वह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई वैकल्पिक डायरेक्ट्री तय की जा सकती है.
`add_exports`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी को दिए गए `module` या `package` को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग से जुड़ा है.
`add_opens`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी को, दिए गए `module` या `package` को रिफ़्लेक्टिव तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग से जुड़ा है.
`bootclasspath`	लेबल; डिफ़ॉल्ट `None` है प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
`exported_plugins`	लेबल की सूची; डिफ़ॉल्ट `[]` है उन लाइब्रेरी में एक्सपोर्ट करने के लिए `java_plugin`s (जैसे, एनोटेशन प्रोसेसर) की सूची जो सीधे इस लाइब्रेरी पर निर्भर करती हैं. `java_plugin` की बताई गई सूची, उन सभी लाइब्रेरी पर लागू की जाएगी जो सीधे तौर पर इस लाइब्रेरी पर निर्भर करती हैं. ऐसा ठीक वैसे ही होगा जैसे उस लाइब्रेरी ने `plugins` में इन लेबल का साफ़ तौर पर एलान किया हो.
`exports`	लेबल की सूची; डिफ़ॉल्ट `[]` है एक्सपोर्ट की गई लाइब्रेरी. यहां लिस्टिंग के नियमों को शामिल करने से, वे पैरंट रूल के लिए उपलब्ध हो जाएंगे. ऐसा तब होगा, जब पैरंट ने साफ़ तौर पर इन नियमों पर निर्भरता दिखाई हो. यह बात सामान्य (एक्सपोर्ट नहीं किए गए) `deps` के लिए लागू नहीं होती. खास जानकारी: कोई नियम X, Y में मौजूद कोड को तब ऐक्सेस कर सकता है, जब उनके बीच कोई डिपेंडेंसी पाथ मौजूद हो. यह पाथ, `deps` एज से शुरू होता है और उसके बाद शून्य या उससे ज़्यादा `exports` एज होते हैं. आइए, इस बारे में कुछ उदाहरणों की मदद से जानते हैं. मान लें कि A, B पर निर्भर करता है और B, C पर निर्भर करता है. इस मामले में, C, A की ट्रांज़िशन डिपेंडेंसी है. इसलिए, C के सोर्स बदलने और A को फिर से बनाने पर, सब कुछ सही तरीके से फिर से बन जाएगा. हालांकि, A, C में मौजूद क्लास का इस्तेमाल नहीं कर पाएगा. इसके लिए, A को अपने `deps` एट्रिब्यूट में C की जानकारी देनी होगी या B अपने `exports` एट्रिब्यूट में C की जानकारी देकर, A और A पर निर्भर किसी भी चीज़ के लिए यह काम आसान बना सकता है. एक्सपोर्ट की गई लाइब्रेरी को बंद करने की सुविधा, सभी डायरेक्ट पैरंट रूल के लिए उपलब्ध है. थोड़ा अलग उदाहरण लें: A, B पर निर्भर करता है, B, C और D पर निर्भर करता है, और C को एक्सपोर्ट भी करता है, लेकिन D को नहीं. अब A के पास C का ऐक्सेस है, लेकिन D का नहीं. अब, अगर C और D ने कुछ लाइब्रेरी, C' और D' को एक्सपोर्ट किया है, तो A सिर्फ़ C' को ऐक्सेस कर सकता है, D' को नहीं. अहम जानकारी: एक्सपोर्ट किया गया नियम, सामान्य डिपेंडेंसी नहीं है. पिछले उदाहरण के हिसाब से, अगर B, C को एक्सपोर्ट करता है और उसे C का इस्तेमाल भी करना है, तो उसे अपने `deps` में भी इसे शामिल करना होगा.
`javabuilder_jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
`neverlink`	बूलियन; डिफ़ॉल्ट तौर पर `False` इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए या रनटाइम के दौरान भी. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट से प्रोग्राम के दौरान उपलब्ध कराया जाएगा. इस तरह की लाइब्रेरी के उदाहरणों में, IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चलने वाली किसी भी चीज़ के लिए `tools.jar` शामिल हैं. ध्यान दें कि `neverlink = True`, कंपाइलर को इस लाइब्रेरी के कॉन्टेंट को, उस पर निर्भर कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता.ऐसा, Java Language Specification के मुताबिक किया जाता है. उदाहरण के लिए, `static final` `String` के कॉन्स्टेंट या प्राइमिटिव टाइप के कॉन्स्टेंट). इसलिए, रनटाइम लाइब्रेरी के लिए, संकलन लाइब्रेरी का इस्तेमाल करना बेहतर होता है. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग हो जहां JLS, कंपाइलर को इनलाइन करने से मना करता है. साथ ही, यह JLS के आने वाले सभी वर्शन के लिए भी लागू होना चाहिए.
`plugins`	लेबल की सूची; डिफ़ॉल्ट `[]` है कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में बताए गए हर `java_plugin` को चलाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से प्लग इन भी इनहेरिट हो सकते हैं जो `exported_plugins` का इस्तेमाल करती हैं. प्लग इन से जनरेट किए गए संसाधन, इस नियम के नतीजे के जार में शामिल किए जाएंगे.
`proguard_specs`	लेबल की सूची; डिफ़ॉल्ट `[]` है Proguard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनमें, Proguard के इस्तेमाल के लिए स्पेसिफ़िकेशन के सेट के बारे में बताया जाएगा. अगर इनका इस्तेमाल किया जाता है, तो इन्हें इस लाइब्रेरी के आधार पर किसी भी `android_binary` टारगेट में जोड़ दिया जाएगा. यहां शामिल फ़ाइलों में सिर्फ़ एक जैसे नियम होने चाहिए. जैसे, -dontnote, -dontwarn, assumenosideeffects, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ `android_binary` के proguard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि टॉटोलॉजिकल मर्ज न हों.
`resource_strip_prefix`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` Java रिसॉर्स से हटाने के लिए पाथ प्रीफ़िक्स. अगर यह पाथ प्रीफ़िक्स दिया गया है, तो `resources` एट्रिब्यूट की हर फ़ाइल से इसे हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर यह जानकारी नहीं दी गई है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के उसी लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद सोर्स फ़ाइल, `foo/bar/a.txt` पर मौजूद होगी.
`runtime_deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है ऐसी लाइब्रेरी जिन्हें फ़ाइनल बाइनरी या सिर्फ़ रनटाइम के दौरान टेस्ट करने के लिए उपलब्ध कराया जाता है. सामान्य `deps` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये `deps` के उलट, कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी को यहां सूची में शामिल किया जाना चाहिए. डिपेंडेंसी-ऐनालिसिस टूल को उन टारगेट को अनदेखा करना चाहिए जो `runtime_deps` और `deps`, दोनों में दिखते हैं.

java_test

नियम का सोर्स देखें

java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, bootclasspath, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, env, env_inherit, exec_compatible_with, exec_group_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, neverlink, package_metadata, plugins, resource_strip_prefix, restricted_to, runtime_deps, shard_count, size, stamp, tags, target_compatible_with, test_class, testonly, timeout, toolchains, use_launcher, use_testrunner, visibility)

java_test() नियम, Java टेस्ट को कंपाइल करता है. टेस्ट, आपके टेस्ट कोड के चारों ओर मौजूद एक बाइनरी रैपर होता है. मुख्य क्लास को कंपाइल करने के बजाय, टेस्ट रनर के मुख्य तरीके को शुरू किया जाता है.

इंप्लिसिट आउटपुट टारगेट

name.jar: Java का संग्रह.
name_deploy.jar: डिप्लॉयमेंट के लिए सही Java संग्रह. (सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया गया हो.) ज़्यादा जानकारी के लिए, java_binary से मिले name_deploy.jar आउटपुट का ब्यौरा देखें.

java_binary() आर्ग्युमेंट वाला सेक्शन देखें. यह नियम, सभी टेस्ट नियमों (*_test) के लिए सामान्य तौर पर इस्तेमाल होने वाले सभी एट्रिब्यूट के साथ भी काम करता है.

उदाहरण



java_library(
    name = "tests",
    srcs = glob(["*.java"]),
    deps = [
        "//java/com/foo/base:testResources",
        "//java/com/foo/testing/util",
    ],
)

java_test(
    name = "AllTests",
    size = "small",
    runtime_deps = [
        ":tests",
        "//util/mysql",
    ],
)

तर्क

विशेषताएं
`name`	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं.
`srcs`	लेबल की सूची; डिफ़ॉल्ट `[]` है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. इस एट्रिब्यूट की वैल्यू सबमिट करना ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, कुछ मामलों में ऐसा नहीं होता. इन अपवादों के बारे में यहां बताया गया है. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई `.java` फ़ाइलों के लिए, आम तौर पर फ़ाइल के नाम के बजाय, जनरेट करने वाले नियम का नाम यहां डालने का सुझाव दिया जाता है. इससे न सिर्फ़ नियम को पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को ज़्यादा बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम का `outs`. आपको `deps` में जनरेट करने वाला नियम नहीं डालना चाहिए, क्योंकि यह कोई काम का नहीं है. `.srcjar` टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर कोई नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए किया जाता है. यह आर्ग्युमेंट ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर किसी क्लास की जानकारी देता है या आपने `runtime_deps` आर्ग्युमेंट दिया है, तो यह ज़रूरी नहीं है.
`data`	लेबल की सूची; डिफ़ॉल्ट `[]` है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. `data` के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों से तय किए गए सामान्य एट्रिब्यूट पर जाएं.
`resources`	लेबल की सूची; डिफ़ॉल्ट `[]` है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट हुई सामान्य `.class` फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह लेआउट, "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री के पोते के तौर पर होता है. अगर वह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई वैकल्पिक डायरेक्ट्री तय की जा सकती है.
`add_exports`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी को दिए गए `module` या `package` को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग से जुड़ा है.
`add_opens`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी को, दिए गए `module` या `package` को रिफ़्लेक्टिव तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग से जुड़ा है.
`bootclasspath`	लेबल; डिफ़ॉल्ट `None` है प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
`classpath_resources`	लेबल की सूची; डिफ़ॉल्ट `[]` है इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई दूसरा विकल्प न हो) उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का एक ही मकसद है, तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना जिनके लिए ज़रूरी है कि उनके रिसॉर्स, क्लासपाथ पर `"myconfig.xml"` के तौर पर मिलें. नेमस्पेस के टकराव की आशंका की वजह से, इसका इस्तेमाल सिर्फ़ बाइनरी में किया जा सकता है, न कि लाइब्रेरी में.
`create_executable`	बूलियन; डिफ़ॉल्ट तौर पर `True` इस सुविधा के इस्तेमाल पर रोक लगा दी गई है. इसके बजाय, `java_single_jar` का इस्तेमाल करें.
`deploy_manifest_lines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` `_deploy.jar` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट में, "वैरिएबल बनाएं" विकल्प का इस्तेमाल करके बदलाव नहीं* किया जा सकता.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस बाइनरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
`jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में जोड़ने के लिए फ़्लैग की सूची. $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से. Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH परिभाषा शामिल होती है, ताकि सभी डिपेंडेंट jar ढूंढे जा सकें. साथ ही, यह सही Java इंटरप्रेटर को भी शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम और उसके बाद `"$@"` होता है, ताकि क्लास के नाम के बाद अन्य आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM के पास पार्स करने के लिए जिन आर्ग्युमेंट का इस्तेमाल करना है उन्हें कमांड लाइन पर क्लास के नाम से पहले तय करना होगा. क्लास का नाम शामिल करने से पहले, `jvm_flags` के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ा जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर* नहीं पड़ता.
`launcher`	लेबल; डिफ़ॉल्ट `None` है JDK में शामिल सामान्य `bin/java` प्रोग्राम के बजाय, अपने Java प्रोग्राम को चलाने के लिए इस्तेमाल किए जाने वाले बाइनरी के बारे में बताएं. टारगेट एक `cc_binary` होना चाहिए. Java Invocation API को लागू करने वाले किसी भी `cc_binary` को इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. इससे जुड़े `--java_launcher` Bazel फ़्लैग का असर सिर्फ़ उन `java_binary` और `java_test` टारगेट पर पड़ता है जिनके लिए `launcher` एट्रिब्यूट की वैल्यू न दी गई है. ध्यान दें कि JDK लॉन्चर या किसी अन्य लॉन्चर का इस्तेमाल करने पर, आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी अलग-अलग तरीके से बनाई जाएंगी: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी को `{name}_nativedeps.so` नाम की शेयर की गई लाइब्रेरी के तौर पर बनाया जाता है. यहां `{name}`, इस java_binary नियम का `name` एट्रिब्यूट है. इस कॉन्फ़िगरेशन में, लिंकर इस्तेमाल न किए गए कोड को नहीं हटाता. अगर किसी दूसरे लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी को `{name}_nativedeps` नाम के बाइनरी में स्टैटिक तौर पर लिंक किया जाता है. यहां `{name}`, इस java_binary नियम का `name` एट्रिब्यूट है. इस मामले में, लिंकर उस कोड को हटा देगा जो उसके हिसाब से, बाइनरी में इस्तेमाल नहीं किया गया है. इसका मतलब है कि सिर्फ़ JNI के ज़रिए ऐक्सेस किया गया कोई भी C++ कोड तब तक लिंक नहीं किया जा सकता, जब तक कि `cc_library` टारगेट में `alwayslink = True` की जानकारी न दी गई हो. डिफ़ॉल्ट JDK लॉन्चर के अलावा किसी दूसरे लॉन्चर का इस्तेमाल करने पर, `*_deploy.jar` आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
`main_class`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, `main()` तरीके वाली क्लास का नाम. अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो उसे `srcs=[...]` सूची की ज़रूरत नहीं होती. इस एट्रिब्यूट की मदद से, किसी ऐसी Java लाइब्रेरी से एक ऐसी एक्सीक्यूटेबल बनाई जा सकती है जिसमें पहले से ही एक या उससे ज़्यादा `main()` तरीके मौजूद हों. इस एट्रिब्यूट की वैल्यू, सोर्स फ़ाइल नहीं, बल्कि क्लास का नाम होती है. क्लास, रनटाइम के दौरान उपलब्ध होनी चाहिए: इसे इस नियम (`srcs` से) से संकलित किया जा सकता है या सीधे या ट्रांज़िशन वाली डिपेंडेंसी (`runtime_deps` या `deps` के ज़रिए) से उपलब्ध कराया जा सकता है. अगर क्लास उपलब्ध नहीं है, तो बाइनरी रनटाइम के दौरान काम नहीं करेगी; बिल्ड के समय कोई जांच नहीं की जाती.
`neverlink`	बूलियन; डिफ़ॉल्ट तौर पर `False`
`plugins`	लेबल की सूची; डिफ़ॉल्ट `[]` है कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में बताए गए हर `java_plugin` को चलाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से प्लग इन भी इनहेरिट हो सकते हैं जो `exported_plugins` का इस्तेमाल करती हैं. प्लग इन से जनरेट किए गए संसाधन, इस नियम के नतीजे के जार में शामिल किए जाएंगे.
`resource_strip_prefix`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` Java रिसॉर्स से हटाने के लिए पाथ प्रीफ़िक्स. अगर यह पाथ प्रीफ़िक्स दिया गया है, तो `resources` एट्रिब्यूट की हर फ़ाइल से इसे हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर यह जानकारी नहीं दी गई है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के उसी लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद सोर्स फ़ाइल, `foo/bar/a.txt` पर मौजूद होगी.
`runtime_deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है ऐसी लाइब्रेरी जिन्हें फ़ाइनल बाइनरी या सिर्फ़ रनटाइम के दौरान टेस्ट करने के लिए उपलब्ध कराया जाता है. सामान्य `deps` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये `deps` के उलट, कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी को यहां सूची में शामिल किया जाना चाहिए. डिपेंडेंसी-ऐनालिसिस टूल को उन टारगेट को अनदेखा करना चाहिए जो `runtime_deps` और `deps`, दोनों में दिखते हैं.
`stamp`	पूर्णांक; डिफ़ॉल्ट वैल्यू `0` है बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. वैल्यू, इनमें से कोई हो सकती है: `stamp = 1`: बिल्डर की जानकारी को हमेशा बाइनरी में स्टैंप करें. ऐसा `--nostamp` बिल्डर में भी करें. इस सेटिंग का इस्तेमाल नहीं किया जाना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल नहीं किया जा सकता. `stamp = 0`: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे, बिल्ड के नतीजे को कैश मेमोरी में सेव करने की सुविधा मिलती है. `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने की सुविधा, `--[no]stamp` फ़्लैग से कंट्रोल की जाती है. स्टैंप की गई बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
`test_class`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` टेस्ट रनर से लोड की जाने वाली Java क्लास. डिफ़ॉल्ट रूप से, अगर इस आर्ग्युमेंट की जानकारी नहीं दी गई है, तो लेगसी मोड का इस्तेमाल किया जाता है और इसके बजाय, टेस्ट आर्ग्युमेंट का इस्तेमाल किया जाता है. पहले आर्ग्युमेंट पर फ़ॉलबैक न करने के लिए, `--nolegacy_bazel_java_test` फ़्लैग सेट करें. इस एट्रिब्यूट से, उस Java क्लास का नाम पता चलता है जिसे इस टेस्ट से चलाया जाना है. आम तौर पर, इसे सेट करने की ज़रूरत नहीं होती. अगर इस आर्ग्युमेंट को छोड़ा जाता है, तो इसे टारगेट के `name` और उसके सोर्स-रूट-रिलेटिव पाथ का इस्तेमाल करके अनुमान लगाया जाएगा. अगर टेस्ट किसी जाने-पहचाने `test_class` सोर्स रूट के बाहर है, तो Bazel गड़बड़ी की रिपोर्ट करेगा. JUnit3 के लिए, टेस्ट क्लास को `junit.framework.TestCase` की सबक्लास होना चाहिए या फिर उसमें ऐसा सार्वजनिक स्टैटिक `suite()` तरीका होना चाहिए जो `junit.framework.Test` (या `Test` की सबक्लास) दिखाता हो. JUnit4 के लिए, क्लास को `org.junit.runner.RunWith` के साथ एनोटेट करना ज़रूरी है. इस एट्रिब्यूट की मदद से, कई `java_test` नियमों के लिए एक ही `Test` (`TestCase`, `TestSuite`, ...) शेयर किया जा सकता है. आम तौर पर, इसमें ज़्यादा जानकारी (जैसे, `jvm_flags=['-Dkey=value']` के ज़रिए) दी जाती है, ताकि हर मामले में इसका व्यवहार अलग हो. जैसे, टेस्ट का कोई दूसरा सबसेट चलाना. इस एट्रिब्यूट की मदद से, `javatests` ट्री के बाहर भी Java टेस्ट का इस्तेमाल किया जा सकता है.
`use_launcher`	बूलियन; डिफ़ॉल्ट तौर पर `True` बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए या नहीं. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो इस टारगेट के लिए लॉन्चर एट्रिब्यूट और उससे जुड़े `--java_launcher` फ़्लैग को अनदेखा कर दिया जाएगा.
`use_testrunner`	बूलियन; डिफ़ॉल्ट तौर पर `True` किसी Java प्रोग्राम के मुख्य एंट्री पॉइंट के तौर पर, टेस्ट रनर (डिफ़ॉल्ट रूप से `com.google.testing.junit.runner.BazelTestRunner`) क्लास का इस्तेमाल करें. साथ ही, टेस्ट रनर को `bazel.test_suite` सिस्टम प्रॉपर्टी की वैल्यू के तौर पर टेस्ट क्लास दें. इसका इस्तेमाल, डिफ़ॉल्ट व्यवहार को बदलने के लिए किया जा सकता है. डिफ़ॉल्ट तौर पर, `java_test` नियमों के लिए टेस्ट रननर का इस्तेमाल किया जाता है और `java_binary` नियमों के लिए इसका इस्तेमाल नहीं किया जाता. ऐसा होने की संभावना कम है. इसका एक इस्तेमाल, `AllTest` उन नियमों के लिए किया जाता है जिन्हें किसी दूसरे नियम से चालू किया जाता है. उदाहरण के लिए, जांच चलाने से पहले डेटाबेस सेट अप करने के लिए. `AllTest` नियम को `java_binary` के तौर पर घोषित किया जाना चाहिए. हालांकि, इसके लिए अब भी टेस्ट रनर को मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करना चाहिए. टेस्ट रनर क्लास के नाम को `main_class` एट्रिब्यूट की मदद से बदला जा सकता है.

java_package_configuration

नियम का सोर्स देखें

java_package_configuration(name, data, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, javacopts, output_licenses, package_metadata, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)

पैकेज के सेट पर लागू करने के लिए कॉन्फ़िगरेशन. कॉन्फ़िगरेशन, java_toolchain.javacopts में जोड़े जा सकते हैं.

उदाहरण:



java_package_configuration(
    name = "my_configuration",
    packages = [":my_packages"],
    javacopts = ["-Werror"],
)

package_group(
    name = "my_packages",
    packages = [
        "//com/my/project/...",
        "-//com/my/project/testing/...",
    ],
)

java_toolchain(
    ...,
    package_configuration = [
        ":my_configuration",
    ]
)

तर्क

विशेषताएं
`name`	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`data`	लेबल की सूची; डिफ़ॉल्ट `[]` है रनटाइम के दौरान, इस कॉन्फ़िगरेशन के लिए ज़रूरी फ़ाइलों की सूची.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` Java कंपाइलर फ़्लैग.
`output_licenses`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]`
`packages`	लेबल की सूची; डिफ़ॉल्ट `[]` है `package_group` का वह सेट जिस पर कॉन्फ़िगरेशन लागू करना है.
`system`	लेबल; डिफ़ॉल्ट `None` है यह javac के --system फ़्लैग से मेल खाता है.

java_plugin

नियम का सोर्स देखें

java_plugin(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, generates_api, javabuilder_jvm_flags, javacopts, licenses, neverlink, output_licenses, package_metadata, plugins, processor_class, proguard_specs, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

java_plugin, Bazel से चलाए जा रहे Java कंपाइलर के लिए प्लग इन तय करता है. सिर्फ़ एनोटेशन प्रोसेसर वाले प्लग इन इस्तेमाल किए जा सकते हैं. java_library या java_binary नियम, plugins एट्रिब्यूट के ज़रिए प्लग इन चला सकता है. java_library, exported_plugins का इस्तेमाल करके, प्लग इन को उन लाइब्रेरी में भी अपने-आप एक्सपोर्ट कर सकता है जो सीधे तौर पर उस पर निर्भर हैं.

इंप्लिसिट आउटपुट टारगेट

libname.jar: Java का संग्रह.

आर्ग्युमेंट, java_library जैसे ही होते हैं. हालांकि, processor_class आर्ग्युमेंट को जोड़ने के अलावा, इनमें कोई अंतर नहीं होता.

तर्क

विशेषताएं
`name`	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है इस लाइब्रेरी से लिंक की जाने वाली लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. `deps` में दिए गए `java_library` नियमों से बनाए गए jar, इस नियम के संकलन के समय के क्लासपथ पर होंगे. इसके अलावा, उनके `deps`, `runtime_deps`, और `exports` के ट्रांज़िटिव क्लोज़र, रनटाइम क्लासपाथ पर होंगे. इसके उलट, `data` एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल होते हैं, लेकिन ये 'कंपाइल के समय' या 'रनटाइम क्लासपाथ' में शामिल नहीं होते.
`srcs`	लेबल की सूची; डिफ़ॉल्ट `[]` है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. इस एट्रिब्यूट की वैल्यू सबमिट करना ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, कुछ मामलों में ऐसा नहीं होता. इन अपवादों के बारे में यहां बताया गया है. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई `.java` फ़ाइलों के लिए, आम तौर पर फ़ाइल के नाम के बजाय, जनरेट करने वाले नियम का नाम यहां डालने का सुझाव दिया जाता है. इससे न सिर्फ़ नियम को पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को ज़्यादा बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम का `outs`. आपको `deps` में जनरेट करने वाला नियम नहीं डालना चाहिए, क्योंकि यह कोई काम का नहीं है. `.srcjar` टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर कोई नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए किया जाता है. `.properties` टाइप की सोर्स फ़ाइलों को संसाधन माना जाता है. ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद होने पर, बाकी सभी फ़ाइलों को अनदेखा कर दिया जाता है. ऐसा न करने पर, गड़बड़ी का मैसेज दिखता है. `runtime_deps` आर्ग्युमेंट के अलावा, इस आर्ग्युमेंट की ज़रूरत हमेशा होती है.
`data`	लेबल की सूची; डिफ़ॉल्ट `[]` है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. `data` के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. `java_library` बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं डालता. अगर `data` फ़ाइलें जनरेट की गई फ़ाइलें हैं, तो Bazel उन्हें जनरेट करता है. इस `java_library` पर निर्भर करने वाले किसी जांच को बनाते समय, Bazel `data` फ़ाइलों को रनफ़ाइल एरिया में कॉपी करता है या लिंक करता है.
`resources`	लेबल की सूची; डिफ़ॉल्ट `[]` है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट हुई सामान्य `.class` फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह लेआउट, "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री के पोते के तौर पर होता है. अगर वह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई वैकल्पिक डायरेक्ट्री तय की जा सकती है.
`add_exports`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी को दिए गए `module` या `package` को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग से जुड़ा है.
`add_opens`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी को, दिए गए `module` या `package` को रिफ़्लेक्टिव तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग से जुड़ा है.
`bootclasspath`	लेबल; डिफ़ॉल्ट `None` है प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
`generates_api`	बूलियन; डिफ़ॉल्ट तौर पर `False` यह एट्रिब्यूट, एनोटेशन प्रोसेसर को मार्क करता है, जो एपीआई कोड जनरेट करते हैं. अगर कोई नियम, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो उस पर निर्भर अन्य नियम, जनरेट किए गए कोड का रेफ़रंस सिर्फ़ तब दे सकते हैं, जब उनके कोड कंपाइल करने की कार्रवाइयां, जनरेट करने वाले नियम के बाद शेड्यूल की गई हों. यह एट्रिब्यूट, Bazel को शेड्यूलिंग से जुड़ी पाबंदियां लागू करने का निर्देश देता है. ऐसा तब होता है, जब --java_header_compilation चालू हो. चेतावनी: इस एट्रिब्यूट से बिल्ड की परफ़ॉर्मेंस पर असर पड़ता है. इसलिए, इसका इस्तेमाल सिर्फ़ ज़रूरत पड़ने पर करें.
`javabuilder_jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
`neverlink`	बूलियन; डिफ़ॉल्ट तौर पर `False` इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए या रनटाइम के दौरान भी. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट से प्रोग्राम के दौरान उपलब्ध कराया जाएगा. इस तरह की लाइब्रेरी के उदाहरणों में, IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चलने वाली किसी भी चीज़ के लिए `tools.jar` शामिल हैं. ध्यान दें कि `neverlink = True`, कंपाइलर को इस लाइब्रेरी के कॉन्टेंट को, उस पर निर्भर कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता.ऐसा, Java Language Specification के मुताबिक किया जाता है. उदाहरण के लिए, `static final` `String` के कॉन्स्टेंट या प्राइमिटिव टाइप के कॉन्स्टेंट). इसलिए, रनटाइम लाइब्रेरी के लिए, संकलन लाइब्रेरी का इस्तेमाल करना बेहतर होता है. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग हो जहां JLS, कंपाइलर को इनलाइन करने से मना करता है. साथ ही, यह JLS के आने वाले सभी वर्शन के लिए भी लागू होना चाहिए.
`output_licenses`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]`
`plugins`	लेबल की सूची; डिफ़ॉल्ट `[]` है कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में बताए गए हर `java_plugin` को चलाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से प्लग इन भी इनहेरिट हो सकते हैं जो `exported_plugins` का इस्तेमाल करती हैं. प्लग इन से जनरेट किए गए संसाधन, इस नियम के नतीजे के जार में शामिल किए जाएंगे.
`processor_class`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` प्रोसेसर क्लास, क्लास का पूरी तरह से क्वालिफ़ाइड टाइप है. Java कंपाइलर को एनोटेशन प्रोसेसर के एंट्री पॉइंट के तौर पर इसका इस्तेमाल करना चाहिए. अगर इसकी जानकारी नहीं दी जाती है, तो यह नियम, Java कंपाइलर के एनोटेशन प्रोसेसिंग में एनोटेशन प्रोसेसर का योगदान नहीं देगा. हालांकि, इसके रनटाइम क्लासपाथ को अब भी कंपाइलर के एनोटेशन प्रोसेसर पाथ में शामिल किया जाएगा. (इसका मुख्य मकसद, ऐसे प्लग इन का इस्तेमाल करना है जिनमें गड़बड़ी होने की संभावना ज़्यादा होती है. इन्हें एनोटेशन प्रोसेसर पाथ से लोड किया जाता है. इसके लिए, java.util.ServiceLoader का इस्तेमाल किया जाता है.)
`proguard_specs`	लेबल की सूची; डिफ़ॉल्ट `[]` है Proguard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनमें, Proguard के इस्तेमाल के लिए स्पेसिफ़िकेशन के सेट के बारे में बताया जाएगा. अगर इनका इस्तेमाल किया जाता है, तो इन्हें इस लाइब्रेरी के आधार पर किसी भी `android_binary` टारगेट में जोड़ दिया जाएगा. यहां शामिल फ़ाइलों में सिर्फ़ एक जैसे नियम होने चाहिए. जैसे, -dontnote, -dontwarn, assumenosideeffects, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ `android_binary` के proguard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि टॉटोलॉजिकल मर्ज न हों.
`resource_strip_prefix`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` Java रिसॉर्स से हटाने के लिए पाथ प्रीफ़िक्स. अगर यह पाथ प्रीफ़िक्स दिया गया है, तो `resources` एट्रिब्यूट की हर फ़ाइल से इसे हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर यह जानकारी नहीं दी गई है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के उसी लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद सोर्स फ़ाइल, `foo/bar/a.txt` पर मौजूद होगी.

java_runtime

नियम का सोर्स देखें

java_runtime(name, srcs, compatible_with, default_cds, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)

Java रनटाइम के लिए कॉन्फ़िगरेशन तय करता है.

उदाहरण:



java_runtime(
    name = "jdk-9-ea+153",
    srcs = glob(["jdk9-ea+153/**"]),
    java_home = "jdk9-ea+153",
)

तर्क

विशेषताएं
`name`	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`srcs`	लेबल की सूची; डिफ़ॉल्ट `[]` है रनटाइम में मौजूद सभी फ़ाइलें.
`default_cds`	लेबल; डिफ़ॉल्ट `None` है पूरी तरह से सुरक्षित `java_runtime` के लिए, सीडीएस का डिफ़ॉल्ट संग्रह. जब किसी `java_binary` टारगेट के लिए, हेर्मेटिक मोड चालू होता है, तो `java_runtime` डिफ़ॉल्ट सीडीएस को हेर्मेटिक डिप्लॉय JAR में पैकेज किया जाता है.
`hermetic_srcs`	लेबल की सूची; डिफ़ॉल्ट `[]` है रनटाइम में मौजूद फ़ाइलें, जो पूरी तरह से सुरक्षित डिप्लॉयमेंट के लिए ज़रूरी हैं.
`hermetic_static_libs`	लेबल की सूची; डिफ़ॉल्ट `[]` है ऐसी लाइब्रेरी जो पूरी तरह से सुरक्षित डिप्लॉयमेंट के लिए, लॉन्चर के साथ स्टैटिक तौर पर लिंक होती हैं
`java`	लेबल; डिफ़ॉल्ट `None` है Java की एक्ज़ीक्यूट की जा सकने वाली फ़ाइल का पाथ.
`java_home`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` रनटाइम के रूट का पाथ. "Make" वैरिएबल के बदले इस्तेमाल किया जा सकता है. अगर यह पाथ एब्सोलूट है, तो नियम से पता चलता है कि यह एक ऐसा Java रनटाइम है जो पूरी तरह से सुरक्षित नहीं है और जिसका पाथ आम तौर पर जाना जाता है. ऐसे में, `srcs` और `java` एट्रिब्यूट की वैल्यू खाली होनी चाहिए.
`lib_ct_sym`	लेबल; डिफ़ॉल्ट `None` है `--release` के साथ कंपाइल करने के लिए, lib/ct.sym फ़ाइल की ज़रूरत होती है. अगर फ़ाइल का पाथ नहीं दिया गया है और `srcs` में ऐसी एक फ़ाइल है जिसका पाथ `/lib/ct.sym` पर खत्म होता है, तो उस फ़ाइल का इस्तेमाल किया जाता है.
`lib_modules`	लेबल; डिफ़ॉल्ट `None` है हेर्मेटिक डिप्लॉयमेंट के लिए, lib/modules फ़ाइल ज़रूरी है.
`output_licenses`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]`
`version`	पूर्णांक; डिफ़ॉल्ट वैल्यू `0` है Java रनटाइम की सुविधा का वर्शन. इसका मतलब है कि `Runtime.version().feature()` से मिलने वाला पूर्णांक.

java_single_jar

नियम का सोर्स देखें

java_single_jar(name, deps, compatible_with, compress, deploy_env, deploy_manifest_lines, deprecation, exclude_build_data, exec_compatible_with, exec_group_compatible_with, exec_properties, features, multi_release, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Java की डिपेंडेंसी और jar फ़ाइलों को एक ही jar में इकट्ठा करता है `java_single_jar`, Java की डिपेंडेंसी और jar फ़ाइलों को एक ही jar में इकट्ठा करता है. यह java_binary के जैसा ही है, जिसमें सभी एक्सीक्यूटेबल बंद हैं. साथ ही, यह java_binary "डिप्लॉय jar हैक" का विकल्प भी उपलब्ध कराता है. ## उदाहरण ```skylark load("//tools/build_defs/java_single_jar:java_single_jar.bzl", "java_single_jar") java_single_jar( name = "my_single_jar", deps = [ "//java/com/google/foo", "//java/com/google/bar", ], ) ``` आउटपुट: {name}.jar: एक ऐसा jar जिसमें सभी इनपुट शामिल होते हैं.

तर्क

विशेषताएं
`name`	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट `[]` है ट्रांज़िटिव डिपेंडेंसी इकट्ठा करने के लिए, Java टारगेट (जैसे कि java_import और java_library). रनटाइम डिपेंडेंसी, deps, exports, और runtime_deps के ज़रिए इकट्ठा की जाती हैं. संसाधन भी इकट्ठा किए जाते हैं. नेटिव cc_library या java_wrap_cc डिपेंडेंसी नहीं हैं.
`compress`	स्ट्रिंग; डिफ़ॉल्ट रूप से `"preserve"` हमेशा डिफ़्लेट करें ("हां"), हमेशा सेव करें ("नहीं") या बिना बदलाव के पास करें ("बचाना"). डिफ़ॉल्ट रूप से, "बचत करें" विकल्प चुना जाता है. यह सबसे बेहतर विकल्प है. इसमें, डेटा को बड़ा या छोटा करने के लिए कोई अतिरिक्त काम नहीं किया जाता.
`deploy_env`	लेबल की सूची; डिफ़ॉल्ट `[]` है `java_binary` या `java_single_jar` टारगेट की सूची, जो इस बाइनरी के लिए डिप्लॉयमेंट एनवायरमेंट दिखाती है. इस एट्रिब्यूट को किसी ऐसे प्लग इन को बनाते समय सेट करें जिसे किसी दूसरे `java_binary` से लोड किया जाएगा. इस नियम से बनाए गए jar से, `deploy_env` डिपेंडेंसी को बाहर रखा जाता है.
`deploy_manifest_lines`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` `META-INF/manifest.mf` फ़ाइल में जोड़ने के लिए लाइनों की सूची.
`exclude_build_data`	बूलियन; डिफ़ॉल्ट तौर पर `True` डिफ़ॉल्ट रूप से जनरेट हुई build-data.properties फ़ाइल को शामिल करना है या नहीं.
`multi_release`	बूलियन; डिफ़ॉल्ट तौर पर `True` एक से ज़्यादा रिलीज़ वाले आउटपुट जार चालू करने हैं या नहीं.

java_toolchain

नियम का सोर्स देखें

java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, exec_compatible_with, exec_group_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, package_metadata, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)

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

उदाहरण

इसका एक आसान उदाहरण यह है:



java_toolchain(
    name = "toolchain",
    source_version = "7",
    target_version = "7",
    bootclasspath = ["//tools/jdk:bootclasspath"],
    xlint = [ "classfile", "divzero", "empty", "options", "path" ],
    javacopts = [ "-g" ],
    javabuilder = ":JavaBuilder_deploy.jar",
)

तर्क

विशेषताएं
`name`	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`android_lint_data`	लेबल की सूची; डिफ़ॉल्ट `[]` है android_lint_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध टूल के लेबल.
`android_lint_jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` Android Lint को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची.
`android_lint_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` Android Lint के आर्ग्युमेंट की सूची.
`android_lint_package_configuration`	लेबल की सूची; डिफ़ॉल्ट `[]` है Android Lint कॉन्फ़िगरेशन, जिसे बताए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
`android_lint_runner`	लेबल; डिफ़ॉल्ट `None` है Android Lint Runner का लेबल, अगर कोई है.
`bootclasspath`	लेबल की सूची; डिफ़ॉल्ट `[]` है Java टारगेट के bootclasspath की एंट्री. यह javac के -bootclasspath फ़्लैग से मेल खाता है.
`compatible_javacopts`	null; डिफ़ॉल्ट `{}` है इंटरनल एपीआई, इसका इस्तेमाल न करें!
`deps_checker`	लेबल; डिफ़ॉल्ट `None` है ImportDepsChecker डिप्लॉय किए गए jar का लेबल.
`forcibly_disable_header_compilation`	बूलियन; डिफ़ॉल्ट तौर पर `False` --java_header_compilation को बदलकर, उन प्लैटफ़ॉर्म पर हेडर कंपाइलेशन की सुविधा बंद की जा सकती है जिन पर यह काम नहीं करता. जैसे, JDK 7 Bazel.
`genclass`	लेबल; डिफ़ॉल्ट `None` है GenClass डिप्लॉय किए गए jar का लेबल.
`header_compiler`	लेबल; डिफ़ॉल्ट `None` है हेडर कंपाइलर का लेबल. --java_header_compilation चालू होने पर ज़रूरी है.
`header_compiler_builtin_processors`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इंटरनल एपीआई, इसका इस्तेमाल न करें!
`header_compiler_direct`	लेबल; डिफ़ॉल्ट `None` है हेडर कंपाइलर का वैकल्पिक लेबल, जिसका इस्तेमाल डायरेक्ट क्लासपथ ऐक्शन के लिए किया जाता है. इन ऐक्शन में, एपीआई जनरेट करने वाले किसी भी एनोटेशन प्रोसेसर को शामिल नहीं किया जाता. इस टूल में एनोटेशन प्रोसेसिंग की सुविधा काम नहीं करती.
`ijar`	लेबल; डिफ़ॉल्ट `None` है ijar एक्सीक्यूटेबल का लेबल.
`jacocorunner`	लेबल; डिफ़ॉल्ट `None` है JacocoCoverageRunner डिप्लॉय किए गए jar का लेबल.
`java_runtime`	लेबल; डिफ़ॉल्ट `None` है इस टूलचेन का इस्तेमाल करने के लिए java_runtime. यह डिफ़ॉल्ट रूप से, java_runtime के एक्ज़ीक्यूशन कॉन्फ़िगरेशन में सेट होता है.
`javabuilder`	लेबल; डिफ़ॉल्ट `None` है JavaBuilder डिप्लॉय किए गए jar का लेबल.
`javabuilder_data`	लेबल की सूची; डिफ़ॉल्ट `[]` है javabuilder_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
`javabuilder_jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` JavaBuilder को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची.
`javac_supports_multiplex_workers`	बूलियन; डिफ़ॉल्ट तौर पर `True` अगर JavaBuilder, मल्टीप्लेक्स पर्सिस्टेंट वर्कर्स के तौर पर काम करता है, तो True. अगर नहीं करता है, तो False.
`javac_supports_worker_cancellation`	बूलियन; डिफ़ॉल्ट तौर पर `True` अगर JavaBuilder, पर्सिस्टेंट वर्कर्स को रद्द करने की सुविधा देता है, तो यह वैल्यू 'सही' होगी. अगर नहीं देता है, तो यह वैल्यू 'गलत' होगी.
`javac_supports_worker_multiplex_sandboxing`	बूलियन; डिफ़ॉल्ट तौर पर `False` अगर JavaBuilder, सैंडबॉक्सिंग की सुविधा के साथ मल्टीप्लेक्स पर्सिस्टेंट वर्कर्स के तौर पर काम करता है, तो यह वैल्यू 'सही' होगी. अगर ऐसा नहीं है, तो यह वैल्यू 'गलत' होगी.
`javac_supports_workers`	बूलियन; डिफ़ॉल्ट तौर पर `True` अगर JavaBuilder, पर्सिस्टेंट वर्कर्स के तौर पर काम करने की सुविधा देता है, तो यह वैल्यू 'सही' होगी. अगर नहीं देता है, तो यह वैल्यू 'गलत' होगी.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` Java कंपाइलर के लिए अतिरिक्त आर्ग्युमेंट की सूची. Java कंपाइलर के फ़्लैग की पूरी सूची के लिए, कृपया Java कंपाइलर के दस्तावेज़ देखें.
`jspecify_implicit_deps`	लेबल; डिफ़ॉल्ट `None` है एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
`jspecify_javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
`jspecify_packages`	लेबल की सूची; डिफ़ॉल्ट `[]` है एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
`jspecify_processor`	लेबल; डिफ़ॉल्ट `None` है एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
`jspecify_processor_class`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
`jspecify_stubs`	लेबल की सूची; डिफ़ॉल्ट `[]` है एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
`jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` Java कंपाइलर को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची. इस विकल्प के लिए, संभावित फ़्लैग की पूरी सूची देखने के लिए, कृपया Java वर्चुअल मशीन के दस्तावेज़ देखें.
`misc`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इस्तेमाल नहीं किया जा सकता: इसके बजाय javacopts का इस्तेमाल करें
`oneversion`	लेबल; डिफ़ॉल्ट `None` है एनफ़ोर्समेंट के लिए इस्तेमाल होने वाले एक वर्शन वाले बाइनरी का लेबल.
`oneversion_allowlist`	लेबल; डिफ़ॉल्ट `None` है एक वर्शन की अनुमति वाली सूची का लेबल.
`oneversion_allowlist_for_tests`	लेबल; डिफ़ॉल्ट `None` है टेस्ट के लिए, एक वर्शन की अनुमति वाली सूची का लेबल.
`oneversion_whitelist`	लेबल; डिफ़ॉल्ट `None` है अब काम नहीं करता: इसके बजाय, oneversion_allowlist का इस्तेमाल करें
`package_configuration`	लेबल की सूची; डिफ़ॉल्ट `[]` है कॉन्फ़िगरेशन, जिसे पैकेज के बताए गए ग्रुप पर लागू करना है.
`proguard_allowlister`	लेबल; डिफ़ॉल्ट `"@bazel_tools//tools/jdk:proguard_whitelister"` है Proguard allowlister का लेबल.
`reduced_classpath_incompatible_processors`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` इंटरनल एपीआई, इसका इस्तेमाल न करें!
`singlejar`	लेबल; डिफ़ॉल्ट `None` है SingleJar डिप्लॉय jar का लेबल.
`source_version`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` Java सोर्स का वर्शन (उदाहरण के लिए, '6' या '7'). इससे पता चलता है कि Java सोर्स कोड में कोड स्ट्रक्चर के कौनसे सेट इस्तेमाल किए जा सकते हैं.
`target_version`	स्ट्रिंग; डिफ़ॉल्ट रूप से `""` Java का टारगेट वर्शन (उदाहरण के लिए, '6' या '7'). इससे पता चलता है कि क्लास को किस Java रनटाइम के लिए बनाया जाना चाहिए.
`timezone_data`	लेबल; डिफ़ॉल्ट `None` है टाइमज़ोन डेटा वाले रिसॉर्स जर्स का लेबल. अगर यह सेट है, तो टाइमज़ोन डेटा को सभी java_binary नियमों की रनटाइम डिपेंडेंसी के तौर पर जोड़ा जाता है.
`tools`	लेबल की सूची; डिफ़ॉल्ट `[]` है jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध टूल के लेबल.
`turbine_data`	लेबल की सूची; डिफ़ॉल्ट `[]` है turbine_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
`turbine_jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` turbine को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची.
`xlint`	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से `[]` डिफ़ॉल्ट सूची में जोड़ने या हटाने के लिए चेतावनी की सूची. इसे हटाने के लिए, इसके पहले डैश लगाएं. ज़्यादा जानकारी के लिए, -Xlint विकल्पों के बारे में Javac दस्तावेज़ देखें.

Java के नियम संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

नियम

java_binary

इंप्लिसिट आउटपुट टारगेट

तर्क

java_import

उदाहरण

तर्क

java_library

इंप्लिसिट आउटपुट

तर्क

java_test

इंप्लिसिट आउटपुट टारगेट

उदाहरण

तर्क

java_package_configuration

उदाहरण:

तर्क

java_plugin

इंप्लिसिट आउटपुट टारगेट

तर्क

java_runtime

उदाहरण:

तर्क

java_single_jar

तर्क

java_toolchain

उदाहरण

तर्क

Java के नियम