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

Java नियम

नियम

java_binary
java_import
java_library
java_lite_proto_library
java_proto_library
java_test
java_package_configuration
java_plugin
java_runtime
java_toolchain

java_binary

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

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

रैपर स्क्रिप्ट कई यूनीक फ़्लैग स्वीकार करती है. रैपर से स्वीकार किए जाने वाले कॉन्फ़िगर किए जा सकने वाले फ़्लैग और एनवायरमेंट वैरिएबल के लिए, //src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt देखें.

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

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

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

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

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`	नाम; ज़रूरी है इस टारगेट के लिए एक खास नाम. सोर्स फ़ाइल के नाम का इस्तेमाल करें. सोर्स फ़ाइल, ऐप्लिकेशन का मुख्य एंट्री पॉइंट है. हालांकि, इसमें एक्सटेंशन शामिल नहीं होता. उदाहरण के लिए, अगर आपके एंट्री पॉइंट को `Main.java` कहा जाता है, तो आपका नाम `Main` हो सकता है.
`deps`	लेबल की सूची; `[]` डिफ़ॉल्ट है टारगेट से लिंक की जाने वाली दूसरी लाइब्रेरी की सूची. ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट पर, `deps` के बारे में की गई सामान्य टिप्पणियां देखें.
`srcs`	लेबल की सूची; `[]` डिफ़ॉल्ट है सोर्स फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. यह एट्रिब्यूट करीब-करीब ज़रूरी होता है. नीचे इसके अपवाद देखें. `.java` प्रकार की स्रोत फ़ाइलें कंपाइल की जाती हैं. आम तौर पर, जनरेट की गई `.java` फ़ाइलों के मामले में, फ़ाइल के नाम के बजाय जनरेट करने के नियम का नाम यहां डालें. इससे न सिर्फ़ रीडबिलिटी बेहतर होती है, बल्कि नियम को आने वाले समय में होने वाले बदलावों के हिसाब से भी आसानी से बदला जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने के नियम का `outs`. आपको `deps` में, जनरेट करने के नियम की जानकारी नहीं देनी चाहिए, क्योंकि इसे इस्तेमाल करने से कोई फ़र्क़ नहीं पड़ता. `.srcjar` प्रकार की स्रोत फ़ाइलें अनपैक और कंपाइल की जाती हैं. (यह तब फ़ायदेमंद होता है, जब आपको `.java` फ़ाइलों का एक सेट जनरेट करने के लिए जनरेट किए जाने वाले नियम की ज़रूरत हो.) नियम: अगर नियम (आम तौर पर, `genrule` या `filegroup`) ऊपर दी गई कोई भी फ़ाइल जनरेट करता है, तो उसका इस्तेमाल सोर्स फ़ाइलों के लिए बताए गए तरीके से ही किया जाएगा. आम तौर पर, इस तर्क की ज़रूरत होती है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर किसी क्लास के बारे में बताता है या आपने `runtime_deps` तर्क दिया है, तो ऐसा नहीं होगा.
`resources`	लेबल की सूची; `[]` डिफ़ॉल्ट है Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें कंपाइलेशन से बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर से तय होती है. Bazel पहले, Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद "रिसॉर्स" डायरेक्ट्री का पोलैंड) खोजता है. अगर यह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर की डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, रिसॉर्स फ़ाइलों के लिए कोई खास डायरेक्ट्री बताने के लिए, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं.
`classpath_resources`	लेबल की सूची; `[]` डिफ़ॉल्ट है इस विकल्प का इस्तेमाल तब न करें, जब आपके पास कोई और तरीका न हो) रिसॉर्स की सूची, जो JavaScript ट्री के रूट में होनी चाहिए. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तीसरे पक्ष की लाइब्रेरी के साथ किया जा सकता है. इसके लिए, यह ज़रूरी है कि उनके रिसॉर्स, क्लासपाथ पर `"myconfig.xml"` के तौर पर मौजूद हों. ऐसा सिर्फ़ बाइनरी पर किया जा सकता है, लाइब्रेरी पर नहीं. ऐसा, नेमस्पेस के विवादों के खतरे की वजह से होता है.
`create_executable`	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; `True` डिफ़ॉल्ट है अब काम नहीं करता, इसके बजाय `java_single_jar` का इस्तेमाल करें.
`deploy_env`	लेबल की सूची; `[]` डिफ़ॉल्ट है `java_binary` के अन्य टारगेट की सूची, जो इस बाइनरी के लिए डिप्लॉयमेंट एनवायरमेंट को दिखाती है. कोई ऐसा प्लगिन बनाते समय इस एट्रिब्यूट को सेट करें जिसे दूसरे `java_binary` से लोड किया जाएगा. इस एट्रिब्यूट को सेट करने पर, इस बाइनरी के रनटाइम क्लासपाथ (और डिप्लॉय किए गए जार) की वे सभी डिपेंडेंसी शामिल नहीं होती हैं जिन्हें इस बाइनरी और `deploy_env` में बताए गए टारगेट के बीच शेयर किया जाता है.
`deploy_manifest_lines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है `_deploy.jar` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट की जगह पर "वैरिएबल बनाएं" लागू नहीं* है.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं.
`jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस बाइनरी को चलाने के लिए, रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. यह विकल्प $(location) और "Make वैरिएबल" के बदले लागू होता है. साथ ही, बर्न शेल टोकनाइज़ेशन पर निर्भर करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, `"$@"` होता है, ताकि क्लास के नाम के बाद, अन्य आर्ग्युमेंट को पास किया जा सके. हालांकि, जेवीएम से पार्स करने के लिए बने तर्कों को, कमांड लाइन पर क्लासनाम से पहले बताया जाना चाहिए. क्लास का नाम शामिल करने से पहले, `jvm_flags` के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं पड़ता*.
`launcher`	लेबल; `None` डिफ़ॉल्ट है कोई बाइनरी बताएं, जिसका इस्तेमाल आपके Java प्रोग्राम को चलाने के लिए किया जाएगा, न कि JDK के साथ शामिल सामान्य `bin/java` प्रोग्राम के लिए. टारगेट `cc_binary` होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, Java Invocation API को लागू करने वाले किसी भी `cc_binary` को वैल्यू के तौर पर दिखाया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. मिलते-जुलते `--java_launcher` बैजल फ़्लैग से, सिर्फ़ उन `java_binary` और `java_test` टारगेट पर असर पड़ता है जिनके लिए `launcher` एट्रिब्यूट नहीं बताया गया है. ध्यान दें कि आपके नेटिव (C++, SWIG, JNI) डिपेंडेंसी इस आधार पर अलग-अलग तरीके से बनाई जाएंगी कि JDK लॉन्चर का इस्तेमाल किया जा रहा है या किसी दूसरे लॉन्चर का: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी `{name}_nativedeps.so` नाम की शेयर की गई लाइब्रेरी के तौर पर बनाई जाती हैं. इसमें `{name}`, इस java_binary नियम का `name` एट्रिब्यूट है. इस कॉन्फ़िगरेशन में, लिंकर ने इस्तेमाल नहीं किया गया कोड नहीं हटाया है. अगर किसी दूसरे लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी, `{name}_nativedeps` नाम की बाइनरी से स्टैटिक रूप से लिंक की जाती हैं. इसमें `{name}` इस java_binary नियम का `name` एट्रिब्यूट है. इस मामले में, लिंक करने वाला टैग, नतीजे में दिखने वाली बाइनरी में मौजूद ऐसे किसी भी कोड को हटा देगा जिसे उसके इस्तेमाल नहीं किया गया है. इसका मतलब है कि जेएनआई से ऐक्सेस किया गया कोई भी C++ कोड तब तक लिंक नहीं किया जा सकता, जब तक उस `cc_library` टारगेट में `alwayslink = 1` की जानकारी न दी गई हो. डिफ़ॉल्ट JDK लॉन्चर के अलावा किसी दूसरे लॉन्चर का इस्तेमाल करने पर, `*_deploy.jar` के आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
`main_class`	स्ट्रिंग; `""` डिफ़ॉल्ट है एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, `main()` तरीके से क्लास का नाम. अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो उसे `srcs=[...]` सूची की ज़रूरत नहीं होती. इसलिए, इस एट्रिब्यूट का इस्तेमाल करके Java लाइब्रेरी से, फ़ाइल को एक्ज़ीक्यूट किया जा सकता है. इसमें, पहले से ही एक या उससे ज़्यादा `main()` तरीके शामिल हैं. इस एट्रिब्यूट की वैल्यू, सोर्स फ़ाइल के बजाय क्लास का नाम है. क्लास, रनटाइम के दौरान उपलब्ध होनी चाहिए: इसे इस नियम के ज़रिए (`srcs` से) कंपाइल किया जा सकता है या डायरेक्ट या ट्रांज़िटिव डिपेंडेंसी (`runtime_deps` या `deps` के ज़रिए) से उपलब्ध कराया जा सकता है. अगर क्लास उपलब्ध नहीं है, तो रनटाइम के दौरान बाइनरी काम नहीं करेगी; बिल्ड के समय की कोई जांच नहीं की जाती.
`plugins`	लेबल की सूची; `[]` डिफ़ॉल्ट है कंपाइल समय पर चलने के लिए Java कंपाइलर प्लगिन. यह नियम बनाए जाने पर, इस एट्रिब्यूट में दिए गए हर `java_plugin` को लागू किया जाएगा. लाइब्रेरी, `exported_plugins` का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लगिन इनहेरिट कर सकती है. प्लगिन से जनरेट किए गए रिसॉर्स, इस नियम के बनने वाले जार में शामिल किए जाएंगे.
`resource_jars`	लेबल की सूची; `[]` डिफ़ॉल्ट है अब काम नहीं करता: इसके बजाय, java_Import और deps या transaction_deps का इस्तेमाल करें.
`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`) क्लास को Java प्रोग्राम के मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करें. साथ ही, टेस्ट रनर को, `bazel.test_suite` सिस्टम प्रॉपर्टी की वैल्यू के तौर पर टेस्ट क्लास दें. इसका इस्तेमाल डिफ़ॉल्ट व्यवहार को बदलने के लिए किया जा सकता है. इसमें `java_test` नियमों के लिए टेस्ट रनर का इस्तेमाल किया जाता है, न कि `java_binary` नियमों के लिए. इसकी संभावना कम है कि आप ऐसा करना चाहेंगे. इसका एक इस्तेमाल `AllTest` नियमों के लिए होता है, जिन्हें किसी दूसरे नियम (उदाहरण के लिए, टेस्ट करने से पहले डेटाबेस सेट अप करने के लिए) से शुरू किया जाता है. `AllTest` नियम को `java_binary` के तौर पर बताया जाना चाहिए. हालांकि, इसके बाद भी टेस्ट रनर को मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करना चाहिए. टेस्ट रनर क्लास के नाम को `main_class` एट्रिब्यूट से बदला जा सकता है.

java_import

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

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

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

उदाहरण

    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 देखें.
`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, गुमाद रखने वाले और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ `android_binary` के proGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि नॉन-टॉलॉजिकल मर्जिंग हो.
`runtime_deps`	लेबल की सूची; `[]` डिफ़ॉल्ट है सिर्फ़ रनटाइम के दौरान जांच करने या फ़ाइनल बाइनरी को उपलब्ध कराने के लिए लाइब्रेरी. java_library.runtime_deps देखें.
`srcjar`	लेबल; `None` डिफ़ॉल्ट है ऐसी JAR फ़ाइल जिसमें कंपाइल की गई JAR फ़ाइलों का सोर्स कोड होता है.

java_library

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

java_library(name, deps, srcs, data, resources, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javacopts, licenses, neverlink, plugins, proguard_specs, resource_jars, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, visibility)

यह नियम, सोर्स को इकट्ठा करके एक .jar फ़ाइल में जोड़ता है.

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

libname.jar: क्लास की फ़ाइलों वाला Java संग्रह.
libname-src.jar: ऐसा संग्रह जिसमें सोर्स होते हैं ("सोर्स जार").

तर्क

एट्रिब्यूट
`name`	नाम; ज़रूरी है इस टारगेट के लिए एक खास नाम.
`deps`	लेबल की सूची; `[]` डिफ़ॉल्ट है इस लाइब्रेरी से लिंक करने के लिए लाइब्रेरी की सूची. ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट पर, `deps` के बारे में की गई सामान्य टिप्पणियां देखें. `deps` में बताए गए `java_library` नियमों के हिसाब से बनाए गए जार, इस नियम के कंपाइल-टाइम क्लासपाथ पर होंगे. इसके अलावा, उनके `deps`, `runtime_deps`, और `exports` के बंद होने का ट्रांज़िशन, रनटाइम क्लासपाथ पर होगा. वहीं दूसरी ओर, `data` एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल किए जाते हैं. हालांकि, कंपाइल-टाइम या रनटाइम क्लासपाथ में से किसी में भी उन्हें शामिल नहीं किया जाता.
`srcs`	लेबल की सूची; `[]` डिफ़ॉल्ट है सोर्स फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. यह एट्रिब्यूट करीब-करीब ज़रूरी होता है. नीचे इसके अपवाद देखें. `.java` प्रकार की स्रोत फ़ाइलें कंपाइल की जाती हैं. आम तौर पर, जनरेट की गई `.java` फ़ाइलों के मामले में, फ़ाइल के नाम के बजाय जनरेट करने के नियम का नाम यहां डालें. इससे न सिर्फ़ रीडबिलिटी बेहतर होती है, बल्कि नियम को आने वाले समय में होने वाले बदलावों के हिसाब से भी आसानी से बदला जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने के नियम का `outs`. आपको `deps` में, जनरेट करने के नियम की जानकारी नहीं देनी चाहिए, क्योंकि इसे इस्तेमाल करने से कोई फ़र्क़ नहीं पड़ता. `.srcjar` प्रकार की स्रोत फ़ाइलें अनपैक और कंपाइल की जाती हैं. (यह तब फ़ायदेमंद होता है, जब आपको `.java` फ़ाइलों का एक सेट जनरेट करने के लिए जनरेट किए जाने वाले नियम की ज़रूरत हो.) नियम: अगर नियम (आम तौर पर, `genrule` या `filegroup`) ऊपर दी गई कोई भी फ़ाइल जनरेट करता है, तो उसका इस्तेमाल सोर्स फ़ाइलों के लिए बताए गए तरीके से ही किया जाएगा. आम तौर पर, इस तर्क की ज़रूरत होती है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर किसी क्लास के बारे में बताता है या आपने `runtime_deps` तर्क दिया है, तो ऐसा नहीं होगा.
`data`	लेबल की सूची; `[]` डिफ़ॉल्ट है रनटाइम के दौरान, इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट पर, `data` के बारे में की गई सामान्य टिप्पणियां देखें. `java_library` बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं रखता है. अगर `data` फ़ाइलें जनरेट की जाती हैं, तो Bazel उन्हें जनरेट करता है. इस `java_library` Bazel पर निर्भर टेस्ट बनाते समय, `data` फ़ाइलों को रनफ़ाइल एरिया में कॉपी या लिंक किया जाता है.
`resources`	लेबल की सूची; `[]` डिफ़ॉल्ट है Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें कंपाइलेशन से बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर से तय होती है. Bazel पहले, Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद "रिसॉर्स" डायरेक्ट्री का पोलैंड) खोजता है. अगर यह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर की डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, रिसॉर्स फ़ाइलों के लिए कोई खास डायरेक्ट्री बताने के लिए, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं.
`exported_plugins`	लेबल की सूची; `[]` डिफ़ॉल्ट है उन लाइब्रेरी में एक्सपोर्ट करने के लिए `java_plugin` की सूची जो सीधे तौर पर इस लाइब्रेरी पर निर्भर हैं. जैसे, एनोटेशन प्रोसेसर. `java_plugin` की बताई गई सूची, सीधे इस लाइब्रेरी पर निर्भर किसी भी लाइब्रेरी पर लागू की जाएगी. यह ठीक वैसे ही की जाती है जैसे उस लाइब्रेरी ने `plugins` में साफ़ तौर पर इन लेबल का एलान किया हो.
`exports`	लेबल की सूची; `[]` डिफ़ॉल्ट है लाइब्रेरी एक्सपोर्ट की गईं. यहां दिए गए लिस्टिंग के नियमों से, वे पैरंट नियमों के लिए उपलब्ध हो जाएंगे. जैसे, माता-पिता साफ़ तौर पर इन नियमों पर निर्भर होते हैं. यह सामान्य (एक्सपोर्ट नहीं किए गए) `deps` के लिए सही नहीं है. खास जानकारी: X नियम को Y में ऐक्सेस कर सकता है. ऐसा तब होता है, जब उनके बीच ऐसा डिपेंडेंसी पाथ मौजूद हो जो `deps` किनारे से शुरू होता है और उसके बाद `exports` किनारे होता है. यह समझने के लिए हम कुछ उदाहरण देखते हैं. मान लें कि A, B पर निर्भर है और B, C पर निर्भर है. इस मामले में, C, A की ट्रांज़िशनिव डिपेंडेंसी है. इसलिए, C के सोर्स बदलने और A को फिर से बनाने पर, हर चीज़ सही तरीके से फिर से बन जाएगी. हालांकि, A, C में क्लास इस्तेमाल नहीं कर पाएगा. इसकी अनुमति देने के लिए, A को अपने `deps` में C का एलान करना होगा या B, 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` में शामिल करना होगा.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं.
`neverlink`	बूलियन; डिफ़ॉल्ट मान `False` है इस लाइब्रेरी का इस्तेमाल, सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए, रनटाइम के दौरान नहीं. यह तब काम आता है, जब स्क्रिप्ट चलाने के दौरान रनटाइम एनवायरमेंट से लाइब्रेरी उपलब्ध कराई जाएगी. आईडीई प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चल रही किसी भी चीज़ के लिए `tools.jar` ऐसी लाइब्रेरी के उदाहरण हैं. ध्यान दें कि `neverlink = 1`, कंपाइलर को इस लाइब्रेरी के कॉन्टेंट को उस पर निर्भर कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता है, जैसा कि Java लैंग्वेज स्पेसिफ़िकेशन में बताई गई अनुमति के हिसाब से होता है (जैसे, `String` के `static final` कॉन्सटेंट या प्रिमिटिव टाइप). इसलिए, इस्तेमाल का पसंदीदा उदाहरण तब होना चाहिए, जब रनटाइम लाइब्रेरी और कंपाइलेशन लाइब्रेरी एक जैसी हो. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग-अलग हो जहां जेएलएस, कंपाइलर के ज़रिए इनलाइन करने की अनुमति नहीं देता है. यह वैल्यू, जेएलएस के आने वाले सभी वर्शन के लिए ज़रूरी है.
`plugins`	लेबल की सूची; `[]` डिफ़ॉल्ट है कंपाइल समय पर चलने के लिए Java कंपाइलर प्लगिन. यह नियम बनाए जाने पर, इस एट्रिब्यूट में दिए गए हर `java_plugin` को लागू किया जाएगा. लाइब्रेरी, `exported_plugins` का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लगिन इनहेरिट कर सकती है. प्लगिन से जनरेट किए गए रिसॉर्स, इस नियम के बनने वाले जार में शामिल किए जाएंगे.
`proguard_specs`	लेबल की सूची; `[]` डिफ़ॉल्ट है ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनमें ProGuard की ओर से इस्तेमाल की जाने वाली खास जानकारी के सेट के बारे में जानकारी दी जाएगी. तय किए जाने पर, उन्हें इस लाइब्रेरी के आधार पर किसी भी `android_binary` टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ एक आदर्श नियम होना चाहिए, जैसे कि -dontnote, -dontwarn, गुमाद रखने वाले और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ `android_binary` के proGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि नॉन-टॉलॉजिकल मर्जिंग हो.
`resource_jars`	लेबल की सूची; `[]` डिफ़ॉल्ट है अब काम नहीं करता: इसके बजाय, java_Import और deps या transaction_deps का इस्तेमाल करें.
`resource_strip_prefix`	स्ट्रिंग; `""` डिफ़ॉल्ट है Java के रिसॉर्स से अलग करने वाला पाथ प्रीफ़िक्स. अगर बताया गया हो, तो इस पाथ प्रीफ़िक्स को `resources` एट्रिब्यूट में मौजूद हर फ़ाइल से हटा दिया जाता है. यह एक गड़बड़ी है कि कोई संसाधन फ़ाइल इस डायरेक्ट्री के तहत नहीं है. अगर इसके बारे में नहीं बताया गया है (डिफ़ॉल्ट तौर पर), तो रिसॉर्स फ़ाइल का पाथ उसी लॉजिक के हिसाब से तय किया जाता है जिससे सोर्स फ़ाइलों का Java पैकेज तय किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद एक सोर्स फ़ाइल `foo/bar/a.txt` में मौजूद होगी.
`runtime_deps`	लेबल की सूची; `[]` डिफ़ॉल्ट है सिर्फ़ रनटाइम के दौरान जांच करने या फ़ाइनल बाइनरी को उपलब्ध कराने के लिए लाइब्रेरी. सामान्य `deps` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे, लेकिन इनसे अलग, कंपाइल-टाइम क्लासपाथ पर नहीं. सिर्फ़ रनटाइम के दौरान ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को `runtime_deps` और `deps`, दोनों में दिखने वाले टारगेट को अनदेखा करना चाहिए.

java_lite_proto_library

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

java_lite_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

java_lite_proto_library, .proto फ़ाइलों से Java कोड जनरेट करता है.

deps को proto_library नियमों के बारे में बताना चाहिए.

उदाहरण:

java_library(
    name = "lib",
    deps = [":foo"],
)

java_lite_proto_library(
    name = "foo",
    deps = [":bar"],
)

proto_library(
    name = "bar",
)

तर्क

एट्रिब्यूट

name

नाम; ज़रूरी है

इस टारगेट के लिए एक खास नाम.

deps

लेबल की सूची; [] डिफ़ॉल्ट है

proto_library नियमों की सूची, जिसके लिए Java कोड जनरेट करना है.

java_proto_library

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

java_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

java_proto_library, .proto फ़ाइलों से Java कोड जनरेट करता है.

deps को proto_library नियमों के बारे में बताना चाहिए.

उदाहरण:

java_library(
    name = "lib",
    deps = [":foo_java_proto"],
)

java_proto_library(
    name = "foo_java_proto",
    deps = [":foo_proto"],
)

proto_library(
    name = "foo_proto",
)

तर्क

एट्रिब्यूट

name

नाम; ज़रूरी है

इस टारगेट के लिए एक खास नाम.

deps

लेबल की सूची; [] डिफ़ॉल्ट है

proto_library नियमों की सूची, जिसके लिए Java कोड जनरेट करना है.

java_test

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

java_test(name, deps, srcs, data, resources, args, classpath_resources, compatible_with, create_executable, deploy_manifest_lines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, javacopts, jvm_flags, launcher, licenses, local, main_class, plugins, resource_jars, 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` प्रकार की स्रोत फ़ाइलें अनपैक और कंपाइल की जाती हैं. (यह तब फ़ायदेमंद होता है, जब आपको `.java` फ़ाइलों का एक सेट जनरेट करने के लिए जनरेट किए जाने वाले नियम की ज़रूरत हो.) नियम: अगर नियम (आम तौर पर, `genrule` या `filegroup`) ऊपर दी गई कोई भी फ़ाइल जनरेट करता है, तो उसका इस्तेमाल सोर्स फ़ाइलों के लिए बताए गए तरीके से ही किया जाएगा. आम तौर पर, इस तर्क की ज़रूरत होती है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर किसी क्लास के बारे में बताता है या आपने `runtime_deps` तर्क दिया है, तो ऐसा नहीं होगा.
`resources`	लेबल की सूची; `[]` डिफ़ॉल्ट है Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें कंपाइलेशन से बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर से तय होती है. Bazel पहले, Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद "रिसॉर्स" डायरेक्ट्री का पोलैंड) खोजता है. अगर यह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर की डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, रिसॉर्स फ़ाइलों के लिए कोई खास डायरेक्ट्री बताने के लिए, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं.
`classpath_resources`	लेबल की सूची; `[]` डिफ़ॉल्ट है इस विकल्प का इस्तेमाल तब न करें, जब आपके पास कोई और तरीका न हो) रिसॉर्स की सूची, जो JavaScript ट्री के रूट में होनी चाहिए. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तीसरे पक्ष की लाइब्रेरी के साथ किया जा सकता है. इसके लिए, यह ज़रूरी है कि उनके रिसॉर्स, क्लासपाथ पर `"myconfig.xml"` के तौर पर मौजूद हों. ऐसा सिर्फ़ बाइनरी पर किया जा सकता है, लाइब्रेरी पर नहीं. ऐसा, नेमस्पेस के विवादों के खतरे की वजह से होता है.
`create_executable`	बूलियन; कॉन्फ़िगर नहीं किया जा सकता; `True` डिफ़ॉल्ट है अब काम नहीं करता, इसके बजाय `java_single_jar` का इस्तेमाल करें.
`deploy_manifest_lines`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है `_deploy.jar` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट की जगह पर "वैरिएबल बनाएं" लागू नहीं* है.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं.
`jvm_flags`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस बाइनरी को चलाने के लिए, रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. यह विकल्प $(location) और "Make वैरिएबल" के बदले लागू होता है. साथ ही, बर्न शेल टोकनाइज़ेशन पर निर्भर करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, `"$@"` होता है, ताकि क्लास के नाम के बाद, अन्य आर्ग्युमेंट को पास किया जा सके. हालांकि, जेवीएम से पार्स करने के लिए बने तर्कों को, कमांड लाइन पर क्लासनाम से पहले बताया जाना चाहिए. क्लास का नाम शामिल करने से पहले, `jvm_flags` के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं पड़ता*.
`launcher`	लेबल; `None` डिफ़ॉल्ट है कोई बाइनरी बताएं, जिसका इस्तेमाल आपके Java प्रोग्राम को चलाने के लिए किया जाएगा, न कि JDK के साथ शामिल सामान्य `bin/java` प्रोग्राम के लिए. टारगेट `cc_binary` होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, Java Invocation API को लागू करने वाले किसी भी `cc_binary` को वैल्यू के तौर पर दिखाया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. मिलते-जुलते `--java_launcher` बैजल फ़्लैग से, सिर्फ़ उन `java_binary` और `java_test` टारगेट पर असर पड़ता है जिनके लिए `launcher` एट्रिब्यूट नहीं बताया गया है. ध्यान दें कि आपके नेटिव (C++, SWIG, JNI) डिपेंडेंसी इस आधार पर अलग-अलग तरीके से बनाई जाएंगी कि JDK लॉन्चर का इस्तेमाल किया जा रहा है या किसी दूसरे लॉन्चर का: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी `{name}_nativedeps.so` नाम की शेयर की गई लाइब्रेरी के तौर पर बनाई जाती हैं. इसमें `{name}`, इस java_binary नियम का `name` एट्रिब्यूट है. इस कॉन्फ़िगरेशन में, लिंकर ने इस्तेमाल नहीं किया गया कोड नहीं हटाया है. अगर किसी दूसरे लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी, `{name}_nativedeps` नाम की बाइनरी से स्टैटिक रूप से लिंक की जाती हैं. इसमें `{name}` इस java_binary नियम का `name` एट्रिब्यूट है. इस मामले में, लिंक करने वाला टैग, नतीजे में दिखने वाली बाइनरी में मौजूद ऐसे किसी भी कोड को हटा देगा जिसे उसके इस्तेमाल नहीं किया गया है. इसका मतलब है कि जेएनआई से ऐक्सेस किया गया कोई भी C++ कोड तब तक लिंक नहीं किया जा सकता, जब तक उस `cc_library` टारगेट में `alwayslink = 1` की जानकारी न दी गई हो. डिफ़ॉल्ट JDK लॉन्चर के अलावा किसी दूसरे लॉन्चर का इस्तेमाल करने पर, `*_deploy.jar` के आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
`main_class`	स्ट्रिंग; `""` डिफ़ॉल्ट है एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, `main()` तरीके से क्लास का नाम. अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो उसे `srcs=[...]` सूची की ज़रूरत नहीं होती. इसलिए, इस एट्रिब्यूट का इस्तेमाल करके Java लाइब्रेरी से, फ़ाइल को एक्ज़ीक्यूट किया जा सकता है. इसमें, पहले से ही एक या उससे ज़्यादा `main()` तरीके शामिल हैं. इस एट्रिब्यूट की वैल्यू, सोर्स फ़ाइल के बजाय क्लास का नाम है. क्लास, रनटाइम के दौरान उपलब्ध होनी चाहिए: इसे इस नियम के ज़रिए (`srcs` से) कंपाइल किया जा सकता है या डायरेक्ट या ट्रांज़िटिव डिपेंडेंसी (`runtime_deps` या `deps` के ज़रिए) से उपलब्ध कराया जा सकता है. अगर क्लास उपलब्ध नहीं है, तो रनटाइम के दौरान बाइनरी काम नहीं करेगी; बिल्ड के समय की कोई जांच नहीं की जाती.
`plugins`	लेबल की सूची; `[]` डिफ़ॉल्ट है कंपाइल समय पर चलने के लिए Java कंपाइलर प्लगिन. यह नियम बनाए जाने पर, इस एट्रिब्यूट में दिए गए हर `java_plugin` को लागू किया जाएगा. लाइब्रेरी, `exported_plugins` का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लगिन इनहेरिट कर सकती है. प्लगिन से जनरेट किए गए रिसॉर्स, इस नियम के बनने वाले जार में शामिल किए जाएंगे.
`resource_jars`	लेबल की सूची; `[]` डिफ़ॉल्ट है अब काम नहीं करता: इसके बजाय, java_Import और deps या transaction_deps का इस्तेमाल करें.
`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` और उसके सोर्स-रूट-रिलेटिव पाथ का इस्तेमाल करके, इसका अनुमान लगाया जाएगा. अगर टेस्ट किसी ऐसे सोर्स रूट के बाहर मौजूद है, जिसकी जानकारी पहले से मौजूद है, तो `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` है टेस्ट रनर (डिफ़ॉल्ट रूप से `com.google.testing.junit.runner.BazelTestRunner`) क्लास को Java प्रोग्राम के मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करें. साथ ही, टेस्ट रनर को, `bazel.test_suite` सिस्टम प्रॉपर्टी की वैल्यू के तौर पर टेस्ट क्लास दें. इसका इस्तेमाल डिफ़ॉल्ट व्यवहार को बदलने के लिए किया जा सकता है. इसमें `java_test` नियमों के लिए टेस्ट रनर का इस्तेमाल किया जाता है, न कि `java_binary` नियमों के लिए. इसकी संभावना कम है कि आप ऐसा करना चाहेंगे. इसका एक इस्तेमाल `AllTest` नियमों के लिए होता है, जिन्हें किसी दूसरे नियम (उदाहरण के लिए, टेस्ट करने से पहले डेटाबेस सेट अप करने के लिए) से शुरू किया जाता है. `AllTest` नियम को `java_binary` के तौर पर बताया जाना चाहिए. हालांकि, इसके बाद भी टेस्ट रनर को मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करना चाहिए. टेस्ट रनर क्लास के नाम को `main_class` एट्रिब्यूट से बदला जा सकता है.

java_package_configuration

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

java_package_configuration(name, data, compatible_with, deprecation, distribs, features, javacopts, licenses, packages, restricted_to, tags, target_compatible_with, testonly, visibility)

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

उदाहरण:

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 कंपाइलर फ़्लैग.
`packages`	लेबल की सूची; `[]` डिफ़ॉल्ट है `package_group` के वे सेट जिन पर कॉन्फ़िगरेशन लागू किया जाना चाहिए.

java_plugin

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

java_plugin(name, deps, srcs, data, resources, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, generates_api, javacopts, licenses, neverlink, output_licenses, plugins, processor_class, proguard_specs, resource_jars, resource_strip_prefix, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

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

processor_class तर्क को जोड़े जाने के अलावा, तर्क, java_library के जैसे ही होते हैं.

तर्क

एट्रिब्यूट
`name`	नाम; ज़रूरी है इस टारगेट के लिए एक खास नाम.
`deps`	लेबल की सूची; `[]` डिफ़ॉल्ट है इस लाइब्रेरी से लिंक करने के लिए लाइब्रेरी की सूची. ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट पर, `deps` के बारे में की गई सामान्य टिप्पणियां देखें. `deps` में बताए गए `java_library` नियमों के हिसाब से बनाए गए जार, इस नियम के कंपाइल-टाइम क्लासपाथ पर होंगे. इसके अलावा, उनके `deps`, `runtime_deps`, और `exports` के बंद होने का ट्रांज़िशन, रनटाइम क्लासपाथ पर होगा. वहीं दूसरी ओर, `data` एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल किए जाते हैं. हालांकि, कंपाइल-टाइम या रनटाइम क्लासपाथ में से किसी में भी उन्हें शामिल नहीं किया जाता.
`srcs`	लेबल की सूची; `[]` डिफ़ॉल्ट है सोर्स फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. यह एट्रिब्यूट करीब-करीब ज़रूरी होता है. नीचे इसके अपवाद देखें. `.java` प्रकार की स्रोत फ़ाइलें कंपाइल की जाती हैं. आम तौर पर, जनरेट की गई `.java` फ़ाइलों के मामले में, फ़ाइल के नाम के बजाय जनरेट करने के नियम का नाम यहां डालें. इससे न सिर्फ़ रीडबिलिटी बेहतर होती है, बल्कि नियम को आने वाले समय में होने वाले बदलावों के हिसाब से भी आसानी से बदला जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने के नियम का `outs`. आपको `deps` में, जनरेट करने के नियम की जानकारी नहीं देनी चाहिए, क्योंकि इसे इस्तेमाल करने से कोई फ़र्क़ नहीं पड़ता. `.srcjar` प्रकार की स्रोत फ़ाइलें अनपैक और कंपाइल की जाती हैं. (यह तब फ़ायदेमंद होता है, जब आपको `.java` फ़ाइलों का एक सेट जनरेट करने के लिए जनरेट किए जाने वाले नियम की ज़रूरत हो.) नियम: अगर नियम (आम तौर पर, `genrule` या `filegroup`) ऊपर दी गई कोई भी फ़ाइल जनरेट करता है, तो उसका इस्तेमाल सोर्स फ़ाइलों के लिए बताए गए तरीके से ही किया जाएगा. आम तौर पर, इस तर्क की ज़रूरत होती है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर किसी क्लास के बारे में बताता है या आपने `runtime_deps` तर्क दिया है, तो ऐसा नहीं होगा.
`data`	लेबल की सूची; `[]` डिफ़ॉल्ट है रनटाइम के दौरान, इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. ज़्यादातर बिल्ड नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट पर, `data` के बारे में की गई सामान्य टिप्पणियां देखें. `java_library` बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं रखता है. अगर `data` फ़ाइलें जनरेट की जाती हैं, तो Bazel उन्हें जनरेट करता है. इस `java_library` Bazel पर निर्भर टेस्ट बनाते समय, `data` फ़ाइलों को रनफ़ाइल एरिया में कॉपी या लिंक किया जाता है.
`resources`	लेबल की सूची; `[]` डिफ़ॉल्ट है Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें कंपाइलेशन से बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर से तय होती है. Bazel पहले, Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद "रिसॉर्स" डायरेक्ट्री का पोलैंड) खोजता है. अगर यह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर की डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, रिसॉर्स फ़ाइलों के लिए कोई खास डायरेक्ट्री बताने के लिए, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं.
`generates_api`	बूलियन; डिफ़ॉल्ट मान `False` है यह एट्रिब्यूट, एपीआई कोड जनरेट करने वाले एनोटेशन प्रोसेसर को मार्क करता है. अगर कोई नियम, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो उस नियम के आधार पर जनरेट किए गए अन्य नियम, जनरेट किए गए कोड को रेफ़र कर सकते हैं. ऐसा तब किया जाता है, जब कंपाइलेशन ऐक्शन, जनरेट करने के नियम के बाद शेड्यूल किया गया हो. यह एट्रिब्यूट, Bazel को --java_header_compilation चालू होने पर शेड्यूल करने से जुड़ी पाबंदियां लागू करने का निर्देश देता है. चेतावनी: इस एट्रिब्यूट से बिल्ड की परफ़ॉर्मेंस पर असर पड़ता है. ज़रूरत होने पर ही इसका इस्तेमाल करें.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं.
`neverlink`	बूलियन; डिफ़ॉल्ट मान `False` है इस लाइब्रेरी का इस्तेमाल, सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए, रनटाइम के दौरान नहीं. यह तब काम आता है, जब स्क्रिप्ट चलाने के दौरान रनटाइम एनवायरमेंट से लाइब्रेरी उपलब्ध कराई जाएगी. आईडीई प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चल रही किसी भी चीज़ के लिए `tools.jar` ऐसी लाइब्रेरी के उदाहरण हैं. ध्यान दें कि `neverlink = 1`, कंपाइलर को इस लाइब्रेरी के कॉन्टेंट को उस पर निर्भर कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता है, जैसा कि Java लैंग्वेज स्पेसिफ़िकेशन में बताई गई अनुमति के हिसाब से होता है (जैसे, `String` के `static final` कॉन्सटेंट या प्रिमिटिव टाइप). इसलिए, इस्तेमाल का पसंदीदा उदाहरण तब होना चाहिए, जब रनटाइम लाइब्रेरी और कंपाइलेशन लाइब्रेरी एक जैसी हो. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग-अलग हो जहां जेएलएस, कंपाइलर के ज़रिए इनलाइन करने की अनुमति नहीं देता है. यह वैल्यू, जेएलएस के आने वाले सभी वर्शन के लिए ज़रूरी है.
`output_licenses`	लाइसेंस का टाइप; डिफ़ॉल्ट तौर पर `["none"]` है `common attributes` देखें
`plugins`	लेबल की सूची; `[]` डिफ़ॉल्ट है कंपाइल समय पर चलने के लिए Java कंपाइलर प्लगिन. यह नियम बनाए जाने पर, इस एट्रिब्यूट में दिए गए हर `java_plugin` को लागू किया जाएगा. लाइब्रेरी, `exported_plugins` का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लगिन इनहेरिट कर सकती है. प्लगिन से जनरेट किए गए रिसॉर्स, इस नियम के बनने वाले जार में शामिल किए जाएंगे.
`processor_class`	स्ट्रिंग; `""` डिफ़ॉल्ट है प्रोसेसर क्लास पूरी तरह क्वालिफ़ाइड क्लास है, जिसे Java कंपाइलर को एनोटेशन प्रोसेसर के एंट्री पॉइंट के तौर पर इस्तेमाल करना चाहिए. अगर इसके बारे में जानकारी नहीं दी गई है, तो यह नियम Java कंपाइलर की एनोटेशन प्रोसेसिंग में, एनोटेशन प्रोसेसर के तौर पर योगदान नहीं देगा. हालांकि, इसके रनटाइम क्लासपाथ को अब भी कंपाइलर के एनोटेशन प्रोसेसर पाथ में शामिल किया जाएगा. (इसका मकसद मुख्य रूप से, गड़बड़ी वाले प्लगिन के इस्तेमाल के लिए है. ये प्लगिन, जानकारी देने वाले प्रोसेसर पाथ से लोड किए जाते हैं. इसके लिए, java.util.ServiceLoader का इस्तेमाल किया जाता है.)
`proguard_specs`	लेबल की सूची; `[]` डिफ़ॉल्ट है ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनमें ProGuard की ओर से इस्तेमाल की जाने वाली खास जानकारी के सेट के बारे में जानकारी दी जाएगी. तय किए जाने पर, उन्हें इस लाइब्रेरी के आधार पर किसी भी `android_binary` टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ एक आदर्श नियम होना चाहिए, जैसे कि -dontnote, -dontwarn, गुमाद रखने वाले और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ `android_binary` के proGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि नॉन-टॉलॉजिकल मर्जिंग हो.
`resource_jars`	लेबल की सूची; `[]` डिफ़ॉल्ट है अब काम नहीं करता: इसके बजाय, java_Import और deps या transaction_deps का इस्तेमाल करें.
`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, distribs, features, hermetic_srcs, java, java_home, lib_ct_sym, lib_modules, licenses, restricted_to, tags, target_compatible_with, testonly, 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` के लिए डिफ़ॉल्ट CDS संग्रह. जब `java_binary` टारगेट के लिए हेमेटिक की सुविधा चालू की जाती है और टारगेट `classlist` एट्रिब्यूट के बारे में बताकर अपना CDS संग्रह नहीं देता है, तो `java_runtime` डिफ़ॉल्ट सीडीएस को हेमेटिक डिप्लॉय JAR में पैक किया जाता है.
`hermetic_srcs`	लेबल की सूची; `[]` डिफ़ॉल्ट है हर्मेटिक डिप्लॉयमेंट के लिए रनटाइम में ज़रूरी फ़ाइलें.
`java`	लेबल; `None` डिफ़ॉल्ट है यह JavaScript एक्ज़ीक्यूटेबल का पाथ है.
`java_home`	स्ट्रिंग; `""` डिफ़ॉल्ट है रनटाइम के रूट का पाथ. "बनाएं" वैरिएबल के विकल्प पर निर्भर करता है. अगर यह पाथ पूरा है, तो यह नियम एक लोकप्रिय पाथ वाले नॉन-हर्मेटिक Java रनटाइम को दिखाता है. ऐसे में, `srcs` और `java` एट्रिब्यूट की वैल्यू डालना ज़रूरी है.
`lib_ct_sym`	लेबल; `None` डिफ़ॉल्ट है `--release` के साथ कंपाइल करने के लिए, lib/ct.sym फ़ाइल की ज़रूरत है. अगर इसके बारे में जानकारी नहीं दी गई है और `srcs` में सिर्फ़ एक ऐसी फ़ाइल है जिसका पाथ `/lib/ct.sym` पर खत्म होता है, तो उस फ़ाइल का इस्तेमाल किया जाएगा.
`lib_modules`	लेबल; `None` डिफ़ॉल्ट है हर्मेटिक डिप्लॉयमेंट के लिए ज़रूरी lib/modules फ़ाइल.
`version`	पूर्णांक; डिफ़ॉल्ट `0` है Java रनटाइम का फ़ीचर वर्शन. इसका मतलब है कि `Runtime.version().feature()` से मिला पूर्णांक.

java_toolchain

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

java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_with, deprecation, deps_checker, distribs, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_workers, javacopts, jvm_opts, licenses, oneversion, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, proguard_allowlister, resourcejar, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, 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 लिंट को शुरू करते समय, JVM के लिए तर्कों की सूची.
`android_lint_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है Android लिंट तर्कों की सूची.
`android_lint_package_configuration`	लेबल की सूची; `[]` डिफ़ॉल्ट है Android लिंट कॉन्फ़िगरेशन, जिसे तय किए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
`android_lint_runner`	लेबल; `None` डिफ़ॉल्ट है अगर कोई Android लिंट रनर है, तो उसका लेबल.
`bootclasspath`	लेबल की सूची; `[]` डिफ़ॉल्ट है Java टारगेट बूटक्लासपाथ की एंट्री. यह javac के -bootclasspath फ़्लैग के मुताबिक है.
`deps_checker`	लेबल की सूची; `[]` डिफ़ॉल्ट है PriceDepsChecker का लेबल, जार को डिप्लॉय करता है.
`forcibly_disable_header_compilation`	बूलियन; डिफ़ॉल्ट मान `False` है जिन प्लैटफ़ॉर्म पर यह सुविधा काम नहीं करती उन पर हेडर कंपाइलेशन बंद करने के लिए --java_header_compilation को बंद करता है. उदाहरण के लिए, JDK 7 Bazel.
`genclass`	लेबल की सूची; ज़रूरी है GenClass का लेबल जार डिप्लॉय करें.
`header_compiler`	लेबल की सूची; `[]` डिफ़ॉल्ट है हेडर कंपाइलर का लेबल. --java_header_compilation के चालू होने पर ज़रूरी है.
`header_compiler_direct`	लेबल की सूची; `[]` डिफ़ॉल्ट है हेडर कंपाइलर का वैकल्पिक लेबल, ताकि डायरेक्ट क्लासपाथ ऐक्शन के लिए इस्तेमाल किया जा सके. इस लेबल में, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर शामिल नहीं होते. इस टूल में एनोटेशन प्रोसेस करने की सुविधा काम नहीं करती.
`ijar`	लेबल की सूची; ज़रूरी है Iजार की एक्ज़ीक्यूटेबल फ़ाइल का लेबल.
`jacocorunner`	लेबल; `None` डिफ़ॉल्ट है JacococoCoverageRunner का लेबल जार डिप्लॉय किया गया.
`java_runtime`	लेबल; ज़रूरी है इस टूलचेन के साथ इस्तेमाल किया जाने वाला java_runtime. एक्ज़ीक्यूशन कॉन्फ़िगरेशन में, यह डिफ़ॉल्ट रूप से java_runtime पर सेट होती है.
`javabuilder`	लेबल की सूची; ज़रूरी है JavaBuilder डिप्लॉय किए गए जार का लेबल.
`javabuilder_data`	लेबल की सूची; `[]` डिफ़ॉल्ट है javaBuilder_jvm_opts में लेबल-एक्सपंशन के लिए उपलब्ध डेटा के लेबल.
`javabuilder_jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है JavaBuilder को शुरू करते समय, JVM के लिए आर्ग्युमेंट की सूची.
`javac_supports_multiplex_workers`	बूलियन; डिफ़ॉल्ट मान `True` है अगर JavaBuilder, मल्टीप्लेक्स परसिस्टेंट वर्कर के तौर पर चलाने की सुविधा देता है, तो 'सही' है. अगर वह नहीं चलता है, तो 'गलत' है.
`javac_supports_workers`	बूलियन; डिफ़ॉल्ट मान `True` है अगर JavaBuilder, परसिस्टेंट वर्कर के तौर पर चलने की सुविधा देता है, तो 'सही' है. अगर वह नहीं चलता है, तो 'गलत' है.
`javacopts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java कंपाइलर के लिए अतिरिक्त आर्ग्युमेंट की सूची. संभावित Java कंपाइलर फ़्लैग की पूरी सूची के लिए, कृपया Java कंपाइलर का दस्तावेज़ देखें.
`jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है Java कंपाइलर को शुरू करते समय, JVM के लिए आर्ग्युमेंट की सूची. इस विकल्प के लिए संभावित फ़्लैग की पूरी सूची देखने के लिए, कृपया Java वर्चुअल मशीन का दस्तावेज़ देखें.
`oneversion`	लेबल; `None` डिफ़ॉल्ट है एक वर्शन वाली नीति लागू करने वाली बाइनरी का लेबल.
`oneversion_allowlist_for_tests`	लेबल; `None` डिफ़ॉल्ट है जांच के लिए एक वर्शन की अनुमति वाली सूची का लेबल.
`oneversion_whitelist`	लेबल; `None` डिफ़ॉल्ट है एक वर्शन वाली व्हाइटलिस्ट का लेबल.
`package_configuration`	लेबल की सूची; `[]` डिफ़ॉल्ट है ऐसा कॉन्फ़िगरेशन जिसे तय किए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
`proguard_allowlister`	लेबल; `"@bazel_tools//tools/jdk:proguard_whitelister"` डिफ़ॉल्ट है ProGuard की अनुमति वाली सूची का लेबल.
`resourcejar`	लेबल की सूची; `[]` डिफ़ॉल्ट है रिसॉर्स जार बिल्डर का इस्तेमाल किया जा सकने वाला लेबल.
`singlejar`	लेबल की सूची; ज़रूरी है SingleJar डिप्लॉय जार का लेबल.
`source_version`	स्ट्रिंग; `""` डिफ़ॉल्ट है Java सोर्स का वर्शन (उदाहरण के लिए, '6' या '7'). यह बताता है कि Java सोर्स कोड में कोड के कौनसे सेट की अनुमति है.
`target_version`	स्ट्रिंग; `""` डिफ़ॉल्ट है Java टारगेट वर्शन (उदाहरण के लिए, '6' या '7'). यह तय करता है कि क्लास को किस Java रनटाइम के लिए बनाया जाना चाहिए.
`timezone_data`	लेबल; `None` डिफ़ॉल्ट है टाइमज़ोन डेटा वाले संसाधन जार का लेबल. अगर इसे सेट किया जाता है, तो टाइमज़ोन डेटा को सभी java_binary नियमों के रनटाइम डिपेंडेंसी के तौर पर जोड़ दिया जाता है.
`tools`	लेबल की सूची; `[]` डिफ़ॉल्ट है jvm_opts में लेबल-बड़ा करने के लिए उपलब्ध टूल के लेबल.
`turbine_data`	लेबल की सूची; `[]` डिफ़ॉल्ट है terbine_jvm_opts में लेबल-बढ़ाने के लिए उपलब्ध डेटा के लेबल.
`turbine_jvm_opts`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है टर्बाइन को शुरू करते समय, JVM के लिए तर्कों की सूची.
`xlint`	स्ट्रिंग की सूची; डिफ़ॉल्ट वैल्यू `[]` है डिफ़ॉल्ट सूची में जोड़ने या उससे हटाने के लिए चेतावनी की सूची. इसके पहले डैश लगाकर इसे हटा दिया जाता है. ज़्यादा जानकारी के लिए, -Xlint विकल्पों पर Javac दस्तावेज़ देखें.