BazelCon 2025 के लिए रजिस्ट्रेशन और सीएफ़पी की प्रक्रिया शुरू हो गई है!

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

Java के नियम

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

नियम

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, aspect_hints, 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 फ़ाइल") बनाता है. साथ ही, नियम के नाम वाली रैपर शेल स्क्रिप्ट भी बनाता है. रैपर शेल स्क्रिप्ट, क्लासपाथ का इस्तेमाल करती है. इसमें अन्य चीज़ों के साथ-साथ, हर उस लाइब्रेरी के लिए एक जार फ़ाइल शामिल होती है जिस पर बाइनरी निर्भर करती है. रैपर शेल स्क्रिप्ट चलाते समय, खाली नहीं है JAVABIN एनवायरमेंट वैरिएबल को Bazel के --java_runtime_version फ़्लैग के ज़रिए तय किए गए वर्शन के मुकाबले प्राथमिकता दी जाएगी.

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

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

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

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

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

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

srcs के बिना, java_binary नियम में deps एट्रिब्यूट का इस्तेमाल नहीं किया जा सकता. ऐसे नियम के लिए, 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 फ़ाइल में मौजूद रिसॉर्स की जगह, प्रोजेक्ट स्ट्रक्चर से तय होती है. 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`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई और विकल्प उपलब्ध न हो) उन संसाधनों की सूची जो Java ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का मकसद सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना है जिनके संसाधनों को क्लासपाथ पर `"myconfig.xml"` के तौर पर ढूंढना ज़रूरी है. इसे सिर्फ़ बाइनरी पर इस्तेमाल किया जा सकता है, लाइब्रेरी पर नहीं. ऐसा नेमस्पेस के टकराव के खतरे की वजह से किया जाता है.
`create_executable`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है इस सुविधा के इस्तेमाल पर रोक लगा दी गई है. इसके बजाय, `java_single_jar` का इस्तेमाल करें.
`deploy_env`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है अन्य `java_binary` टारगेट की सूची, जो इस बाइनरी के लिए डिप्लॉयमेंट एनवायरमेंट को दिखाती है. इस एट्रिब्यूट को तब सेट करें, जब आपको ऐसा प्लगिन बनाना हो जिसे किसी अन्य `java_binary` से लोड किया जाएगा. इस एट्रिब्यूट को सेट करने से, इस बाइनरी के रनटाइम क्लासपाथ (और डिप्लॉय जार) से वे सभी डिपेंडेंसी हट जाती हैं जिन्हें इस बाइनरी और `deploy_env` में बताए गए टारगेट के बीच शेयर किया जाता है.
`deploy_manifest_lines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है `META-INF/manifest.mf` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ने के लिए लाइनों की सूची.`_deploy.jar` इस एट्रिब्यूट के कॉन्टेंट को "बदलाव करें" सुविधा का इस्तेमाल करके बदला नहीं* जा सकता.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस बाइनरी के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. कंपाइलर के इन विकल्पों को, ग्लोबल कंपाइलर के विकल्पों के बाद javac को पास किया जाता है.
`jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. यह $(location) और "वैरिएबल बनाएं" के साथ-साथ बोर्न शेल टोकनाइज़ेशन के हिसाब से काम करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH की परिभाषा शामिल होती है. इससे सभी डिपेंडेंट जार फ़ाइलें मिलती हैं. साथ ही, यह सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम शामिल होता है. इसके बाद, `"$@"` होता है, ताकि क्लास के नाम के बाद अन्य आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM के ज़रिए पार्स किए जाने वाले आर्ग्युमेंट को कमांड लाइन पर क्लासनेम से पहले तय किया जाना चाहिए. `jvm_flags` का कॉन्टेंट, रैपर स्क्रिप्ट में क्लासनेम से पहले जोड़ा जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं पड़ता*.
`launcher`	लेबल; डिफ़ॉल्ट वैल्यू `None` है उस बाइनरी के बारे में बताएं जिसका इस्तेमाल, JDK में शामिल सामान्य `bin/java` प्रोग्राम के बजाय, Java प्रोग्राम को चलाने के लिए किया जाएगा. टारगेट `cc_binary` होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, ऐसे किसी भी `cc_binary` का इस्तेमाल किया जा सकता है जो Java Invocation API लागू करता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. इससे जुड़ा `--java_launcher` Bazel फ़्लैग, सिर्फ़ उन `java_binary` और `java_test` टारगेट पर असर डालता है जिनमें `launcher` एट्रिब्यूट नहीं बताया गया है. ध्यान दें कि आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी अलग-अलग तरीके से बनाई जाएंगी. यह इस बात पर निर्भर करता है कि JDK लॉन्चर का इस्तेमाल किया जा रहा है या किसी अन्य लॉन्चर का: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी को `{name}_nativedeps.so` नाम की शेयर की गई लाइब्रेरी के तौर पर बनाया जाता है. यहां `{name}_nativedeps.so`, java_binary नियम का `name` एट्रिब्यूट है.`{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` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, उनसे अलग, ये कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को उन टारगेट को अनदेखा करना चाहिए जो `runtime_deps` और `deps`, दोनों में दिखते हैं.
`stamp`	पूर्णांक; डिफ़ॉल्ट वैल्यू `-1` है बिल्ड की जानकारी को बाइनरी में कोड में बदलना है या नहीं. वैल्यू, इनमें से कोई हो सकती है: `stamp = 1`: बाइनरी में हमेशा बिल्ड की जानकारी स्टैंप करें. भले ही, वह `--nostamp` बिल्ड हो. इस सेटिंग का इस्तेमाल नहीं करना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर डाउनस्ट्रीम कार्रवाइयों के लिए रिमोट कैश मेमोरी बंद हो जाती है. `stamp = 0`: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे, बिल्ड के नतीजों को बेहतर तरीके से कैश मेमोरी में सेव किया जा सकता है. `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने की सुविधा, `--[no]stamp` फ़्लैग से कंट्रोल की जाती है. स्टैंप किए गए बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
`use_launcher`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है क्या बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो इस टारगेट के लिए लॉन्चर एट्रिब्यूट और इससे जुड़ा `--java_launcher` फ़्लैग अनदेखा कर दिया जाएगा.
`use_testrunner`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है जावा प्रोग्राम के मुख्य एंट्री पॉइंट के तौर पर, टेस्ट रनर (डिफ़ॉल्ट रूप से `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, aspect_hints, 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 API या स्टैंडर्ड 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, aspect_hints, 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: यह एक ऐसा संग्रह है जिसमें सोर्स ("source jar") शामिल होते हैं.

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी में लिंक की जाने वाली लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखें. ये टिप्पणियां ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट के बारे में हैं. `deps` में दी गई `java_library` के नियमों के हिसाब से बनाए गए जार, इस नियम के कंपाइल-टाइम क्लासपाथ पर होंगे. इसके अलावा, उनके `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 फ़ाइल में मौजूद रिसॉर्स की जगह, प्रोजेक्ट स्ट्रक्चर से तय होती है. 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` की सूची (जैसे, एनोटेशन प्रोसेसर). इन्हें उन लाइब्रेरी में एक्सपोर्ट किया जाता है जो सीधे तौर पर इस लाइब्रेरी पर निर्भर करती हैं. `java_plugin` की दी गई सूची, सीधे तौर पर इस लाइब्रेरी पर निर्भर करने वाली किसी भी लाइब्रेरी पर लागू होगी. ऐसा तब होगा, जब उस लाइब्रेरी ने `plugins` में इन लेबल का साफ़ तौर पर एलान किया हो.
`exports`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है एक्सपोर्ट की गई लाइब्रेरी. यहां लिस्टिंग के नियम जोड़ने से, वे पैरंट नियमों के लिए उपलब्ध हो जाएंगे. ऐसा लगेगा कि पैरंट नियम, इन नियमों पर साफ़ तौर पर निर्भर हैं. यह बात, सामान्य (एक्सपोर्ट नहीं किए गए) `deps` पर लागू नहीं होती. खास जानकारी: अगर X, Y में मौजूद कोड को ऐक्सेस कर सकता है. इसे समझने के लिए, कुछ उदाहरण देखते हैं. मान लें कि A, B पर निर्भर है और B, C पर निर्भर है. इस मामले में, C, A की ट्रांज़िटिव डिपेंडेंसी है. इसलिए, C के सोर्स बदलने और A को फिर से बनाने पर, सब कुछ सही तरीके से फिर से बन जाएगा. हालांकि, A, C में मौजूद क्लास का इस्तेमाल नहीं कर पाएगा. इसके लिए, A को अपने `deps` में C के बारे में बताना होगा. इसके अलावा, B अपने `exports` एट्रिब्यूट में C के बारे में बताकर, A और A पर निर्भर किसी भी चीज़ के लिए इसे आसान बना सकता है. एक्सपोर्ट की गई लाइब्रेरी बंद करने की सुविधा, सीधे तौर पर पैरंट रूल पर लागू होती है. यहां एक और उदाहरण दिया गया है: A, B पर निर्भर करता है. B, C और D पर निर्भर करता है. साथ ही, B, C को एक्सपोर्ट करता है, लेकिन D को नहीं. अब A के पास C का ऐक्सेस है, लेकिन D का नहीं. अब अगर C और D ने कुछ लाइब्रेरी एक्सपोर्ट की हैं, तो C' और D' के तौर पर, A सिर्फ़ C' को ऐक्सेस कर सकता है, लेकिन D' को नहीं. अहम जानकारी: एक्सपोर्ट किया गया नियम, सामान्य डिपेंडेंसी नहीं होता. पिछले उदाहरण के मुताबिक, अगर B, C को एक्सपोर्ट करता है और उसे इस्तेमाल भी करना चाहता है, तो उसे C को अपने `deps` में भी लिस्ट करना होगा.
`javabuilder_jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है यह प्रतिबंधित एपीआई है. इसका इस्तेमाल न करें!
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. कंपाइलर के इन विकल्पों को, ग्लोबल कंपाइलर के विकल्पों के बाद 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` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, उनसे अलग, ये कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को उन टारगेट को अनदेखा करना चाहिए जो `runtime_deps` और `deps`, दोनों में दिखते हैं.

java_test

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

java_test(name, deps, srcs, data, resources, add_exports, add_opens, args, aspect_hints, 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 संग्रह. (इसे सिर्फ़ तब बनाया जाता है, जब साफ़ तौर पर अनुरोध किया जाता है.) ज़्यादा जानकारी के लिए, name_deploy.jar 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 फ़ाइल में मौजूद रिसॉर्स की जगह, प्रोजेक्ट स्ट्रक्चर से तय होती है. 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`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई और विकल्प उपलब्ध न हो) उन संसाधनों की सूची जो Java ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का मकसद सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना है जिनके संसाधनों को क्लासपाथ पर `"myconfig.xml"` के तौर पर ढूंढना ज़रूरी है. इसे सिर्फ़ बाइनरी पर इस्तेमाल किया जा सकता है, लाइब्रेरी पर नहीं. ऐसा नेमस्पेस के टकराव के खतरे की वजह से किया जाता है.
`create_executable`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है इस सुविधा के इस्तेमाल पर रोक लगा दी गई है. इसके बजाय, `java_single_jar` का इस्तेमाल करें.
`deploy_manifest_lines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है `META-INF/manifest.mf` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ने के लिए लाइनों की सूची.`_deploy.jar` इस एट्रिब्यूट के कॉन्टेंट को "बदलाव करें" सुविधा का इस्तेमाल करके बदला नहीं* जा सकता.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस बाइनरी के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. कंपाइलर के इन विकल्पों को, ग्लोबल कंपाइलर के विकल्पों के बाद javac को पास किया जाता है.
`jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. यह $(location) और "वैरिएबल बनाएं" के साथ-साथ बोर्न शेल टोकनाइज़ेशन के हिसाब से काम करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH की परिभाषा शामिल होती है. इससे सभी डिपेंडेंट जार फ़ाइलें मिलती हैं. साथ ही, यह सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम शामिल होता है. इसके बाद, `"$@"` होता है, ताकि क्लास के नाम के बाद अन्य आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM के ज़रिए पार्स किए जाने वाले आर्ग्युमेंट को कमांड लाइन पर क्लासनेम से पहले तय किया जाना चाहिए. `jvm_flags` का कॉन्टेंट, रैपर स्क्रिप्ट में क्लासनेम से पहले जोड़ा जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं पड़ता*.
`launcher`	लेबल; डिफ़ॉल्ट वैल्यू `None` है उस बाइनरी के बारे में बताएं जिसका इस्तेमाल, JDK में शामिल सामान्य `bin/java` प्रोग्राम के बजाय, Java प्रोग्राम को चलाने के लिए किया जाएगा. टारगेट `cc_binary` होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, ऐसे किसी भी `cc_binary` का इस्तेमाल किया जा सकता है जो Java Invocation API लागू करता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. इससे जुड़ा `--java_launcher` Bazel फ़्लैग, सिर्फ़ उन `java_binary` और `java_test` टारगेट पर असर डालता है जिनमें `launcher` एट्रिब्यूट नहीं बताया गया है. ध्यान दें कि आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी अलग-अलग तरीके से बनाई जाएंगी. यह इस बात पर निर्भर करता है कि JDK लॉन्चर का इस्तेमाल किया जा रहा है या किसी अन्य लॉन्चर का: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी को `{name}_nativedeps.so` नाम की शेयर की गई लाइब्रेरी के तौर पर बनाया जाता है. यहां `{name}_nativedeps.so`, java_binary नियम का `name` एट्रिब्यूट है.`{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` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, उनसे अलग, ये कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को उन टारगेट को अनदेखा करना चाहिए जो `runtime_deps` और `deps`, दोनों में दिखते हैं.
`stamp`	पूर्णांक; डिफ़ॉल्ट वैल्यू `0` है बिल्ड की जानकारी को बाइनरी में कोड में बदलना है या नहीं. वैल्यू, इनमें से कोई हो सकती है: `stamp = 1`: बाइनरी में हमेशा बिल्ड की जानकारी स्टैंप करें. भले ही, वह `--nostamp` बिल्ड हो. इस सेटिंग का इस्तेमाल नहीं करना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर डाउनस्ट्रीम कार्रवाइयों के लिए रिमोट कैश मेमोरी बंद हो जाती है. `stamp = 0`: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे, बिल्ड के नतीजों को बेहतर तरीके से कैश मेमोरी में सेव किया जा सकता है. `stamp = -1`: बिल्ड की जानकारी को एम्बेड करने की सुविधा, `--[no]stamp` फ़्लैग से कंट्रोल की जाती है. स्टैंप किए गए बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
`test_class`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `""` है यह Java क्लास, टेस्ट रनर से लोड की जाती है. डिफ़ॉल्ट रूप से, अगर इस आर्ग्युमेंट को तय नहीं किया जाता है, तो लेगसी मोड का इस्तेमाल किया जाता है. साथ ही, टेस्ट आर्ग्युमेंट का इस्तेमाल किया जाता है. पहले आर्ग्युमेंट पर फ़ॉलबैक न करने के लिए, `--nolegacy_bazel_java_test` फ़्लैग सेट करें. इस एट्रिब्यूट का इस्तेमाल, उस Java क्लास का नाम बताने के लिए किया जाता है जिसे इस टेस्ट के ज़रिए चलाया जाना है. इस विकल्प को सेट करने की ज़रूरत बहुत कम ही पड़ती है. इस आर्ग्युमेंट को शामिल न करने पर, टारगेट के `name` और उसके सोर्स-रूट के हिसाब से पाथ का इस्तेमाल किया जाएगा. अगर टेस्ट, किसी जाने-पहचाने सोर्स रूट से बाहर है, तो Bazel गड़बड़ी की सूचना देगा. ऐसा तब होगा, जब `test_class` सेट नहीं किया गया हो. JUnit3 के लिए, टेस्ट क्लास को `junit.framework.TestCase` का सबक्लास होना चाहिए. इसके अलावा, इसमें एक सार्वजनिक स्टैटिक `suite()` तरीका होना चाहिए, जो `junit.framework.Test` (या `Test` का सबक्लास) दिखाता हो. इस एट्रिब्यूट की मदद से, कई `java_test` नियमों को एक ही `Test` (`TestCase`, `TestSuite`, ...) शेयर करने की अनुमति मिलती है. आम तौर पर, इसे अतिरिक्त जानकारी (जैसे, `jvm_flags=['-Dkey=value']` के ज़रिए) दी जाती है, ताकि हर मामले में इसका व्यवहार अलग-अलग हो. जैसे, टेस्ट का कोई दूसरा सबसेट चलाना. इस एट्रिब्यूट की मदद से, `javatests` ट्री के बाहर Java टेस्ट का इस्तेमाल भी किया जा सकता है.
`use_launcher`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है क्या बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो इस टारगेट के लिए लॉन्चर एट्रिब्यूट और इससे जुड़ा `--java_launcher` फ़्लैग अनदेखा कर दिया जाएगा.
`use_testrunner`	बूलियन; डिफ़ॉल्ट वैल्यू `True` है जावा प्रोग्राम के मुख्य एंट्री पॉइंट के तौर पर, टेस्ट रनर (डिफ़ॉल्ट रूप से `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, aspect_hints, 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, aspect_hints, 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, प्लगिन को उन लाइब्रेरी में भी अपने-आप एक्सपोर्ट कर सकता है जो java_library का इस्तेमाल करके सीधे तौर पर इस पर निर्भर करती हैं.exported_plugins

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

libname.jar: यह एक Java संग्रह है.

आर्ग्युमेंट, java_library() के आर्ग्युमेंट का सबसेट है. साथ ही, इनके सिमैंटिक भी एक जैसे हैं. हालांकि, इनमें processor_class और generates_api आर्ग्युमेंट जोड़े गए हैं.

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी में लिंक की जाने वाली लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखें. ये टिप्पणियां ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट के बारे में हैं. `deps` में दी गई `java_library` के नियमों के हिसाब से बनाए गए जार, इस नियम के कंपाइल-टाइम क्लासपाथ पर होंगे. इसके अलावा, उनके `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 फ़ाइल में मौजूद रिसॉर्स की जगह, प्रोजेक्ट स्ट्रक्चर से तय होती है. 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`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "वैरिएबल बनाएं" के हिसाब से बदलाव किया जा सकता है. साथ ही, बोर्न शेल टोकनाइज़ेशन के हिसाब से बदलाव किया जा सकता है. कंपाइलर के इन विकल्पों को, ग्लोबल कंपाइलर के विकल्पों के बाद 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, aspect_hints, 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` है lib/ct.sym फ़ाइल, `--release` के साथ कंपाइल करने के लिए ज़रूरी है. अगर यह जानकारी नहीं दी गई है और `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, aspect_hints, 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 "deploy jar hack" का विकल्प देता है. ## उदाहरण ```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: इसमें सभी इनपुट शामिल होते हैं.

तर्क

विशेषताएं
`name`	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
`deps`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java टारगेट (java_import और java_library शामिल हैं), जिनसे ट्रांज़िटिव डिपेंडेंसी इकट्ठा करनी हैं. रनटाइम डिपेंडेंसी को deps, exports, और runtime_deps के ज़रिए इकट्ठा किया जाता है. संसाधन भी इकट्ठा किए जाते हैं. नेटिव cc_library या java_wrap_cc डिपेंडेंसी नहीं हैं.
`compress`	स्ट्रिंग; डिफ़ॉल्ट वैल्यू `"preserve"` है यह तय करता है कि डेटा को हमेशा डिफ़्लेट ("yes") करना है, हमेशा सेव ("no") करना है या बिना बदलाव किए पास करना है ("preserve"). डिफ़ॉल्ट वैल्यू "preserve" होती है. यह सबसे सही विकल्प है. इसमें वैल्यू को बढ़ाने या घटाने के लिए, कोई अतिरिक्त काम नहीं किया जाता.
`deploy_env`	लेबल की सूची; डिफ़ॉल्ट वैल्यू `[]` है `java_binary` या `java_single_jar` टारगेट की सूची. ये टारगेट, इस बाइनरी के लिए डिप्लॉयमेंट एनवायरमेंट को दिखाते हैं. इस एट्रिब्यूट को तब सेट करें, जब आपको ऐसा प्लगिन बनाना हो जिसे किसी दूसरे `java_binary` से लोड किया जाएगा. `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, aspect_hints, 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 के टारगेट बूटक्लाथपाथ की एंट्री. यह javac के -bootclasspath फ़्लैग के बराबर है.
`compatible_javacopts`	शून्य; डिफ़ॉल्ट वैल्यू `{}` है यह इंटरनल एपीआई है. इसका इस्तेमाल न करें!
`deps_checker`	लेबल; डिफ़ॉल्ट वैल्यू `None` है ImportDepsChecker को डिप्लॉय करने वाले JAR का लेबल.
`forcibly_disable_header_compilation`	बूलियन; डिफ़ॉल्ट वैल्यू `False` है यह विकल्प, --java_header_compilation को ओवरराइड करता है.इससे उन प्लैटफ़ॉर्म पर हेडर कंपाइलेशन बंद हो जाता है जहां यह सुविधा काम नहीं करती. जैसे, JDK 7 Bazel.
`genclass`	लेबल; डिफ़ॉल्ट वैल्यू `None` है GenClass को डिप्लॉय करने वाले जार का लेबल.
`header_compiler`	लेबल; डिफ़ॉल्ट वैल्यू `None` है हेडर कंपाइलर का लेबल. अगर --java_header_compilation चालू है, तो यह विकल्प ज़रूरी है.
`header_compiler_builtin_processors`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है यह इंटरनल एपीआई है. इसका इस्तेमाल न करें!
`header_compiler_direct`	लेबल; डिफ़ॉल्ट वैल्यू `None` है हेडर कंपाइलर का वैकल्पिक लेबल, जिसका इस्तेमाल डायरेक्ट क्लासपाथ ऐक्शन के लिए किया जाता है. इसमें एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर शामिल नहीं होते. यह टूल, एनोटेशन प्रोसेसिंग की सुविधा के साथ काम नहीं करता.
`ijar`	लेबल; डिफ़ॉल्ट वैल्यू `None` है ijar एक्ज़ीक्यूटेबल का लेबल.
`jacocorunner`	लेबल; डिफ़ॉल्ट वैल्यू `None` है JacocoCoverageRunner के डिप्लॉय जार का लेबल.
`java_runtime`	लेबल; डिफ़ॉल्ट वैल्यू `None` है इस टूलचेन के साथ इस्तेमाल करने के लिए java_runtime. यह डिफ़ॉल्ट रूप से, एक्ज़ीक्यूशन कॉन्फ़िगरेशन में java_runtime पर सेट होता है.
`javabuilder`	लेबल; डिफ़ॉल्ट वैल्यू `None` है JavaBuilder की डिप्लॉय जार फ़ाइल का लेबल.
`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 की अनुमति वाली सूची का लेबल.
`reduced_classpath_incompatible_processors`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है यह इंटरनल एपीआई है. इसका इस्तेमाल न करें!
`singlejar`	लेबल; डिफ़ॉल्ट वैल्यू `None` है SingleJar डिप्लॉय जार का लेबल.
`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`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है टर्बाइन को चालू करते समय, 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 के नियम