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

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

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

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

  अपने नियम के लिए <name>_deploy.jar टारगेट बनाने पर, मेनिफ़ेस्ट के साथ पूरी जानकारी वाली एक जार फ़ाइल बनती है. इससे, इसे java -jar कमांड या रैपर स्क्रिप्ट के --singlejar विकल्प की मदद से चलाया जा सकता है. java -jar को रैपर स्क्रिप्ट का इस्तेमाल करने का सुझाव दिया जाता है, क्योंकि यह JVM फ़्लैग और नेटिव लाइब्रेरी लोड करने के विकल्प भी पास करता है.

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

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

• name_deploy-src.jar: एक संग्रह जिसमें टारगेट के सीमित किए जाने के समय से इकट्ठा किए गए सोर्स मौजूद होते हैं. ये उन deploy.jar की क्लास से मेल खाएंगे जिनमें जार का कोई मिलता-जुलता सोर्स नहीं है.

java_binary नियम में srcs के बिना, 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	लेबल की सूची; [] डिफ़ॉल्ट है इस विकल्प का इस्तेमाल तब न करें, जब आपके पास कोई और तरीका न हो) उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का मकसद सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना होता है जिनके लिए ज़रूरी है कि उनके संसाधन क्लासपाथ पर ठीक "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) और "वैरिएबल बनाएं" से बदलने और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, "$@" होता है, ताकि क्लास के नाम के बाद, दूसरे आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM के ज़रिए पार्स करने के लिए बनाए गए तर्क, कमांड लाइन पर क्लासनाम से पहले तय किए जाने चाहिए. क्लास का नाम शामिल करने से पहले, jvm_flags के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट का *_deploy.jar आउटपुट पर कोई असर नहीं पड़ता.
launcher	लेबल; None डिफ़ॉल्ट है कोई बाइनरी डालें, जिसका इस्तेमाल JDK के साथ शामिल सामान्य bin/java प्रोग्राम के बजाय, आपके Java प्रोग्राम को चलाने के लिए किया जाएगा. टारगेट cc_binary होना चाहिए. Java इनवोकेशन एपीआई लागू करने वाले किसी भी cc_binary को, इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. मिलते-जुलते --java_launcher Bazel फ़्लैग का असर सिर्फ़ उन java_binary और java_test टारगेट पर पड़ता है जिनमें launcher एट्रिब्यूट तय नहीं किया गया है. ध्यान दें कि आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी इस आधार पर अलग-अलग होंगी कि आप JDK लॉन्चर का इस्तेमाल कर रहे हैं या किसी दूसरे लॉन्चर का: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो {name}_nativedeps.so नाम की शेयर की गई लाइब्रेरी के तौर पर नेटिव डिपेंडेंसी बनाई जाती हैं. यहां {name}, इस java_binary नियम का name एट्रिब्यूट है. इस्तेमाल नहीं किए गए कोड को इस कॉन्फ़िगरेशन में लिंकर, हटा नहीं देता है. अगर किसी दूसरे लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी, स्टैटिक रूप से {name}_nativedeps नाम की बाइनरी से लिंक की जाती हैं. इसमें {name}, इस java_binary नियम का name एट्रिब्यूट है. इस मामले में, लिंकर को लगता है कि नतीजे पाने वाली बाइनरी से ऐसे कोड को हटा दिया जाएगा जिसका इस्तेमाल नहीं हुआ है. इसका मतलब है कि सिर्फ़ JNI से ऐक्सेस किए गए 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 या रनटाइम_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) क्लास का इस्तेमाल करें. साथ ही, टेस्ट रनर को bazel.test_suite सिस्टम प्रॉपर्टी की वैल्यू के तौर पर, टेस्ट क्लास दें. डिफ़ॉल्ट व्यवहार को बदलने के लिए, इसका इस्तेमाल किया जा सकता है. इसमें java_test नियमों के लिए, टेस्ट रनर का इस्तेमाल किया जाता है, न कि java_binary नियमों के लिए. इस बात की संभावना कम है कि आप ऐसा करना चाहें. इसका एक इस्तेमाल AllTest नियमों के लिए है, जिन्हें किसी दूसरे नियम से शुरू किया गया है (उदाहरण के लिए, टेस्ट चलाने से पहले डेटाबेस सेट अप करने के लिए). AllTest नियम को java_binary के तौर पर बताया जाना चाहिए. हालांकि, अब भी टेस्ट रनर को मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करना चाहिए. टेस्ट रनर क्लास के नाम को main_class एट्रिब्यूट से बदला जा सकता है.

java_import

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

java_import(name, deps, data, add_exports, add_opens, compatible_with, constraints, deprecation, distribs, exec_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, 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 देखें.
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, -dontvarn, assumenosideimpact और -keep से शुरू होने वाले नियम. दूसरे विकल्प सिर्फ़ android_binary के proGuard_specs में ही दिख सकते हैं, ताकि नॉन-टॉलॉजिकल इंटिग्रेशन को पक्का किया जा सके.
runtime_deps	लेबल की सूची; [] डिफ़ॉल्ट है फ़ाइनल बाइनरी को उपलब्ध कराने या रनटाइम के दौरान टेस्ट के लिए उपलब्ध लाइब्रेरी. java_library.runtime_deps देखें.
srcjar	लेबल; None डिफ़ॉल्ट है ऐसी JAR फ़ाइल जिसमें कंपाइल की गई JAR फ़ाइलों का सोर्स कोड होता है.

java_library

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

java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, 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) ऊपर दी गई सूची में मौजूद कोई भी फ़ाइल जनरेट करता है, तो उसका इस्तेमाल सोर्स फ़ाइलों में बताए गए तरीके से ही किया जाएगा. .properties टाइप की सोर्स फ़ाइलों को संसाधन माना जाता है. दूसरी सभी फ़ाइलों को तब तक अनदेखा किया जाता है, जब तक ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद न हो. ऐसा न होने पर, गड़बड़ी का मैसेज मिलता है. यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर आपने 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 एट्रिब्यूट का इस्तेमाल किया जा सकता है.
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 में कोड को ऐक्सेस कर सकता है. ऐसा तब होता है, जब उनके बीच डिपेंडेंसी पाथ मौजूद होता है, जो deps किनारे से शुरू होता है और उसके बाद exports किनारे होते हैं. इसे समझाने के लिए हम कुछ उदाहरण देखते हैं. मान लें कि A, B पर निर्भर है और B, C पर निर्भर है. इस मामले में, C, A की ट्रांज़िशनिव डिपेंडेंसी है. इसलिए, C के सोर्स बदलने और A को फिर से बनाने से, सब कुछ फिर से बनाने में मदद मिलेगी. हालांकि, A, C में क्लास इस्तेमाल नहीं कर पाएगा. इसकी अनुमति देने के लिए, A को deps में C का एलान करना होगा या B, A (और A पर निर्भर किसी भी चीज़) के लिए, (B की) exports एट्रिब्यूट में C का एलान करके, के लिए आसान बना सकता है. एक्सपोर्ट की गई लाइब्रेरी को बंद करने की सुविधा, सभी पैरंट नियमों के लिए उपलब्ध है. एक अलग उदाहरण लें: A, B पर निर्भर करता है, B पर C और D पर निर्भर करता है. साथ ही, C को एक्सपोर्ट करता है, D पर नहीं. अब A के पास C का ऐक्सेस है, लेकिन D का नहीं. अब, अगर C और D ने कुछ लाइब्रेरी, C' और D' को एक्सपोर्ट किया है, तो A सिर्फ़ C' को ऐक्सेस कर सकता था, D' को नहीं. ज़रूरी जानकारी: एक्सपोर्ट किया गया नियम, सामान्य डिपेंडेंसी नहीं है. पिछले उदाहरण की तरह ही, अगर B, C को एक्सपोर्ट करता है और उसे C का भी इस्तेमाल करना चाहता है, तो उसे भी इसे अपने deps में शामिल करना होगा.
javabuilder_jvm_flags	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
javacopts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है इस लाइब्रेरी के लिए कंपाइलर के और विकल्प. "वैरिएबल बनाएं" से बदलना और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद, javac को पास किए जाते हैं.
neverlink	बूलियन; डिफ़ॉल्ट False है क्या इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए, रनटाइम के लिए नहीं. यह तब काम आता है, जब प्रोग्राम चलाने के दौरान रनटाइम एनवायरमेंट से लाइब्रेरी दी जाएगी. ऐसी लाइब्रेरी के उदाहरण, IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चल रहे किसी भी आइटम के लिए tools.jar हैं. ध्यान दें कि neverlink = 1, कंपाइलर को इस लाइब्रेरी के कॉन्टेंट को उस पर निर्भर कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता है. जैसा कि Java लैंग्वेज स्पेसिफ़िकेशन की अनुमति के साथ, String या प्रिमिटिव टाइप के static final कॉन्सटेंट). इसलिए, इस सुविधा के इस्तेमाल का सुझाव तब दिया जाता है, जब रनटाइम लाइब्रेरी और कंपाइलेशन लाइब्रेरी एक जैसी हो. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग-अलग हो जहां जेएलएस, कंपाइलर को इनलाइन करने की अनुमति नहीं देता है. साथ ही, इसे जेएलएस के आने वाले सभी वर्शन के लिए भी होल्ड किया जाना चाहिए.
plugins	लेबल की सूची; [] डिफ़ॉल्ट है कंपाइलेशन समय पर चलाए जाने के लिए Java कंपाइलर प्लगिन. यह नियम बनाए जाने पर, इस एट्रिब्यूट में दिए गए हर java_plugin को चलाया जाएगा. लाइब्रेरी, exported_plugins का इस्तेमाल करने वाली डिपेंडेंसी से प्लग इन इनहेरिट कर सकती है. प्लग इन से जनरेट किए गए संसाधन, इस नियम के जार में शामिल किए जाएंगे.
proguard_specs	लेबल की सूची; [] डिफ़ॉल्ट है ProGuard विशेषताओं के रूप में इस्तेमाल की जाने वाली फ़ाइलें. इन निर्देशों में ProGuard की ओर से इस्तेमाल की जाने वाली खास जानकारी के बारे में बताया जाएगा. अगर पहले से तय किया गया है, तो उन्हें इस लाइब्रेरी के आधार पर किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ एक आदर्श नियम होना चाहिए, जैसे कि -dontnote, -dontvarn, assumenosideimpact और -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_lite_proto_library

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

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

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

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

उदाहरण:

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

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

proto_library(
    name = "bar",
)

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; [] डिफ़ॉल्ट है इसके लिए Java कोड जनरेट करने के proto_library नियमों के नियमों की सूची.

java_proto_library

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

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

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

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

उदाहरण:

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

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

proto_library(
    name = "foo_proto",
)

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; [] डिफ़ॉल्ट है इसके लिए Java कोड जनरेट करने के proto_library नियमों के नियमों की सूची.

java_test

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

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

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

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

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

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

उदाहरण

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

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

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; [] डिफ़ॉल्ट है टारगेट में लिंक की जाने वाली दूसरी लाइब्रेरी की सूची. ज़्यादातर बिल्ड रूल के तय किए गए एट्रिब्यूट पर, deps के बारे में सामान्य टिप्पणियां देखें.
srcs	लेबल की सूची; [] डिफ़ॉल्ट है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. यह एट्रिब्यूट हमेशा ज़रूरी होता है; अपवाद नीचे देखें. .java प्रकार की स्रोत फ़ाइलें कंपाइल की जाती हैं. आम तौर पर, जनरेट की गई .java फ़ाइलों के मामले में, फ़ाइल के नाम के बजाय जनरेट करने वाले नियम का नाम यहां डालना चाहिए. इससे न सिर्फ़ पढ़ने में आसानी होती है, बल्कि यह नियम को आने वाले समय में होने वाले बदलावों के हिसाब से भी बेहतर बनाता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम के outs. आपको deps में जनरेट करने वाले नियम की जानकारी नहीं देनी चाहिए, क्योंकि यह एक सेशन नहीं है. .srcjar प्रकार की स्रोत फ़ाइलें अनपैक और कंपाइल की जाती हैं. (यह तब काम आता है, जब आपको जेनरूल की मदद से .java फ़ाइलों का सेट जनरेट करने की ज़रूरत हो.) नियम: अगर नियम (आम तौर पर genrule या filegroup) ऊपर दी गई सूची में मौजूद कोई भी फ़ाइल जनरेट करता है, तो उसका इस्तेमाल सोर्स फ़ाइलों में बताए गए तरीके से ही किया जाएगा. यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर main_class एट्रिब्यूट, रनटाइम क्लासपाथ में किसी क्लास के बारे में बताता है या runtime_deps तर्क के बारे में बताता है, तो ऐसा नहीं किया जा सकता.
data	लेबल की सूची; [] डिफ़ॉल्ट है रनटाइम के दौरान, इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. ज़्यादातर बिल्ड रूल के तय किए गए एट्रिब्यूट पर, data के बारे में सामान्य टिप्पणियां देखें.
resources	लेबल की सूची; [] डिफ़ॉल्ट है Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं. अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें जार में, कंपाइलेशन से बनाई गई सामान्य .class फ़ाइलों के साथ बंडल किया जाएगा. जार फ़ाइल में रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर से तय होती है. Bazel सबसे पहले, Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को ढूंढता है, (एक "src" डायरेक्ट्री के बाद "संसाधन" डायरेक्ट्री का पोताइल्ड). अगर वह नहीं मिलता, तो Bazel "java" या "javatests" नाम की सबसे ऊपर की डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई रिसॉर्स <workspace root>/x/java/y/java/z पर है, तो संसाधन का पाथ y/java/z होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, संसाधन फ़ाइलों के लिए किसी खास दूसरी डायरेक्ट्री के बारे में बताने के लिए resource_strip_prefix एट्रिब्यूट का इस्तेमाल किया जा सकता है.
add_exports	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है इस लाइब्रेरी को दिए गए module या package को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग के मुताबिक होता है.
add_opens	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है इस लाइब्रेरी को दिए गए module या package को बेहतर तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग के मुताबिक है.
bootclasspath	लेबल; None डिफ़ॉल्ट है प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
classpath_resources	लेबल की सूची; [] डिफ़ॉल्ट है इस विकल्प का इस्तेमाल तब न करें, जब आपके पास कोई और तरीका न हो) उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का मकसद, तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना होता है जिनके संसाधनों को क्लासपाथ पर "myconfig.xml" होना ज़रूरी है. नेमस्पेस के विवादों के खतरे की वजह से इसे सिर्फ़ बाइनरी पर अनुमति दी जाती है, लाइब्रेरी पर नहीं.
create_executable	बूलियन; डिफ़ॉल्ट True है अब काम नहीं करता, इसके बजाय java_single_jar का इस्तेमाल करें.
deploy_manifest_lines	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है *_deploy.jar टारगेट के लिए जनरेट की गई META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट की जगह "वैरिएबल" का इस्तेमाल नहीं किया जा सकता.
javacopts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है इस बाइनरी के लिए कंपाइलर के ज़्यादा विकल्प. "वैरिएबल बनाएं" से बदलना और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद, javac को पास किए जाते हैं.
jvm_flags	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है इस बाइनरी को चलाने के लिए, जनरेट की गई रैपर स्क्रिप्ट में जोड़े जाने वाले फ़्लैग की सूची. यह $(location) और "वैरिएबल" के बदले में, और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में मुख्य क्लास का नाम होता है, जिसके बाद "$@" होता है, ताकि आप क्लास के नाम के बाद दूसरे आर्ग्युमेंट पास कर सकें. हालांकि, JVM के ज़रिए पार्स करने के लिए बनाए गए तर्क, कमांड लाइन पर क्लासनाम से पहले बताए जाने चाहिए. क्लास का नाम शामिल करने से पहले, jvm_flags के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ा जाता है. ध्यान दें कि इस एट्रिब्यूट का *_deploy.jar आउटपुट पर कोई असर नहीं पड़ता.
launcher	लेबल; None डिफ़ॉल्ट है कोई बाइनरी डालें, जिसका इस्तेमाल JDK के साथ शामिल सामान्य bin/java प्रोग्राम के बजाय, आपके Java प्रोग्राम को चलाने के लिए किया जाएगा. टारगेट cc_binary होना चाहिए. Java Invocat API को लागू करने वाले किसी भी cc_binary को, इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. मिलते-जुलते --java_launcher Bazel फ़्लैग का असर सिर्फ़ उन java_binary और java_test टारगेट पर पड़ता है जिनके लिए launcher एट्रिब्यूट तय नहीं किया गया है. ध्यान दें कि आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी इस आधार पर अलग-अलग तरीके से बनाई जाएंगी कि आप JDK लॉन्चर का इस्तेमाल कर रहे हैं या किसी दूसरे लॉन्चर का: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो {name}_nativedeps.so नाम की शेयर की गई लाइब्रेरी के तौर पर नेटिव डिपेंडेंसी बनाई जाती है. यहां {name} इस java_binary नियम का name एट्रिब्यूट है. इस्तेमाल नहीं किए गए कोड को इस कॉन्फ़िगरेशन में लिंकर, हटा नहीं देता है. अगर किसी दूसरे लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी को स्टैटिक तरीके से {name}_nativedeps नाम की बाइनरी से लिंक किया जाता है. यहां {name}, इस java_binary नियम का name एट्रिब्यूट है. इस मामले में, लिंकर ऐसे किसी भी कोड को हटा देगा जिसके बारे में उसे लगता है कि नतीजे पाने वाली बाइनरी से वह इस्तेमाल नहीं हुआ है. इसका मतलब है कि हो सकता है कि सिर्फ़ JNI से ऐक्सेस किए गए C++ कोड को तब तक लिंक न किया जाए, जब तक वह cc_library टारगेट alwayslink = 1 के बारे में न बता दे. डिफ़ॉल्ट 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 और उसके सोर्स-रूट-रिलेटिव पाथ का इस्तेमाल करके, इसका अनुमान लगाया जाएगा. अगर टेस्ट किसी जाने-पहचाने सोर्स रूट के बाहर मौजूद है, तो test_class के सेट न होने पर, Bazel गड़बड़ी की शिकायत करेगा. JUnit3 के लिए, टेस्ट क्लास को junit.framework.TestCase की सब-क्लास होना चाहिए या इसमें junit.framework.Test (या Test की सब-क्लास) दिखाने वाला पब्लिक स्टैटिक suite() तरीका होना चाहिए. 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, exec_compatible_with, exec_properties, features, javacopts, output_licenses, packages, restricted_to, 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 का वह सेट जिस पर कॉन्फ़िगरेशन लागू किया जाना चाहिए.

java_plugin

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

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

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

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

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

processor_class तर्क को जोड़े जाने को छोड़कर, तर्क और java_library एक जैसे होते हैं.

तर्क

विशेषताएं
name	नाम; ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; [] डिफ़ॉल्ट है इस लाइब्रेरी से लिंक करने के लिए लाइब्रेरी की सूची. ज़्यादातर बिल्ड रूल के तय किए गए एट्रिब्यूट पर, deps के बारे में सामान्य टिप्पणियां देखें. deps में दिए गए java_library नियमों के मुताबिक बनाए गए जार, इस नियम के कंपाइल-टाइम क्लासपाथ पर होंगे. इसके अलावा, उनके deps, runtime_deps, और exports के बंद होने की जानकारी रनटाइम क्लासपाथ पर रहेगी. वहीं दूसरी ओर, data एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल किए जाते हैं. हालांकि, न तो कंपाइल-टाइम और न ही रनटाइम क्लासपाथ में.
srcs	लेबल की सूची; [] डिफ़ॉल्ट है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. यह एट्रिब्यूट हमेशा ज़रूरी होता है; अपवाद नीचे देखें. .java प्रकार की स्रोत फ़ाइलें कंपाइल की जाती हैं. आम तौर पर, जनरेट की गई .java फ़ाइलों के मामले में, फ़ाइल के नाम के बजाय जनरेट करने वाले नियम का नाम यहां डालना चाहिए. इससे न सिर्फ़ पढ़ने में आसानी होती है, बल्कि यह नियम को आने वाले समय में होने वाले बदलावों के हिसाब से भी बेहतर बनाता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम के outs. आपको deps में जनरेट करने वाले नियम की जानकारी नहीं देनी चाहिए, क्योंकि यह एक सेशन नहीं है. .srcjar प्रकार की स्रोत फ़ाइलें अनपैक और कंपाइल की जाती हैं. (यह तब काम आता है, जब आपको जेनरूल की मदद से .java फ़ाइलों का सेट जनरेट करने की ज़रूरत हो.) नियम: अगर नियम (आम तौर पर genrule या filegroup) ऊपर दी गई सूची में मौजूद कोई भी फ़ाइल जनरेट करता है, तो उसका इस्तेमाल सोर्स फ़ाइलों में बताए गए तरीके से ही किया जाएगा. .properties टाइप की सोर्स फ़ाइलों को संसाधन माना जाता है. दूसरी सभी फ़ाइलों को तब तक अनदेखा किया जाता है, जब तक ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद न हो. ऐसा न होने पर, गड़बड़ी का मैसेज मिलता है. यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर आपने 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 एट्रिब्यूट का इस्तेमाल किया जा सकता है.
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 = 1, कंपाइलर को इस लाइब्रेरी के कॉन्टेंट को उस पर निर्भर कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता है. जैसा कि Java लैंग्वेज स्पेसिफ़िकेशन की अनुमति के साथ, String या प्रिमिटिव टाइप के static final कॉन्सटेंट). इसलिए, इस सुविधा के इस्तेमाल का सुझाव तब दिया जाता है, जब रनटाइम लाइब्रेरी और कंपाइलेशन लाइब्रेरी एक जैसी हो. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग-अलग हो जहां जेएलएस, कंपाइलर को इनलाइन करने की अनुमति नहीं देता है. साथ ही, इसे जेएलएस के आने वाले सभी वर्शन के लिए भी होल्ड किया जाना चाहिए.
output_licenses	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है
plugins	लेबल की सूची; [] डिफ़ॉल्ट है कंपाइलेशन समय पर चलाए जाने के लिए Java कंपाइलर प्लगिन. यह नियम बनाए जाने पर, इस एट्रिब्यूट में दिए गए हर java_plugin को चलाया जाएगा. लाइब्रेरी, exported_plugins का इस्तेमाल करने वाली डिपेंडेंसी से प्लग इन इनहेरिट कर सकती है. प्लग इन से जनरेट किए गए संसाधन, इस नियम के जार में शामिल किए जाएंगे.
processor_class	स्ट्रिंग; "" डिफ़ॉल्ट तौर पर सेट है प्रोसेसर क्लास पूरी तरह क्वालिफ़ाइड क्लास है जिसका इस्तेमाल Java कंपाइलर को एनोटेशन प्रोसेसर के एंट्री पॉइंट के तौर पर करना चाहिए. अगर इसके बारे में नहीं बताया गया है, तो यह नियम Java कंपाइलर की एनोटेशन प्रोसेसिंग में, किसी एनोटेशन प्रोसेसर का योगदान नहीं करेगा. हालांकि, इसके रनटाइम क्लासपाथ को अब भी कंपाइलर के एनोटेशन प्रोसेसर पाथ में शामिल किया जाएगा. (इसे मुख्य तौर पर गड़बड़ी प्रोन प्लगिन की मदद से इस्तेमाल करने के लिए बनाया गया है. इन्हें java.util.ServiceLoader का इस्तेमाल करके, एनोटेशन प्रोसेसर पाथ से लोड किया जाता है.)
proguard_specs	लेबल की सूची; [] डिफ़ॉल्ट है ProGuard विशेषताओं के रूप में इस्तेमाल की जाने वाली फ़ाइलें. इन निर्देशों में ProGuard की ओर से इस्तेमाल की जाने वाली खास जानकारी के बारे में बताया जाएगा. अगर पहले से तय किया गया है, तो उन्हें इस लाइब्रेरी के आधार पर किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ एक आदर्श नियम होना चाहिए, जैसे कि -dontnote, -dontvarn, assumenosideimpact और -keep से शुरू होने वाले नियम. दूसरे विकल्प सिर्फ़ android_binary के proGuard_specs में ही दिख सकते हैं, ताकि नॉन-टॉलॉजिकल इंटिग्रेशन को पक्का किया जा सके.
resource_strip_prefix	स्ट्रिंग; "" डिफ़ॉल्ट तौर पर सेट है Java रिसॉर्स से अलग करने के लिए पाथ प्रीफ़िक्स. अगर बताया गया है, तो इस पाथ प्रीफ़िक्स को resources एट्रिब्यूट में मौजूद हर फ़ाइल से हटा दिया जाता है. यह एक गड़बड़ी है कि संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है. अगर इसकी वैल्यू तय नहीं की गई है (डिफ़ॉल्ट तौर पर), तो संसाधन फ़ाइल का पाथ उसी लॉजिक के हिसाब से तय किया जाता है जिससे सोर्स फ़ाइलों का Java पैकेज तय किया जाता है. उदाहरण के लिए, stuff/java/foo/bar/a.txt पर मौजूद सोर्स फ़ाइल foo/bar/a.txt में मौजूद होगी.

java_runtime

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

java_runtime(name, srcs, compatible_with, default_cds, deprecation, distribs, exec_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, 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 के लिए डिफ़ॉल्ट CDS संग्रह. अगर java_binary टारगेट के लिए हेरमेटिक सुविधा चालू की जाती है और टारगेट classlist एट्रिब्यूट में जानकारी देकर अपना CDS संग्रह उपलब्ध नहीं कराता है, तो java_runtime डिफ़ॉल्ट सीडीएस को हेमेटिक डिप्लॉय JAR में पैकेज किया जाता है.
hermetic_srcs	लेबल की सूची; [] डिफ़ॉल्ट है हर्मेटिक डिप्लॉयमेंट के लिए ज़रूरी रनटाइम में फ़ाइलें.
hermetic_static_libs	लेबल की सूची; [] डिफ़ॉल्ट है वे लाइब्रेरी जो हर्मेटिक डिप्लॉयमेंट के लिए लॉन्चर के साथ स्टैटिक रूप से लिंक की गई हैं
java	लेबल; None डिफ़ॉल्ट है JavaScript एक्ज़ीक्यूटेबल का पाथ.
java_home	स्ट्रिंग; "" डिफ़ॉल्ट तौर पर सेट है रनटाइम के रूट का पाथ. "बनाएं" वैरिएबल के सब्सिटिट्यूशन पर निर्भर करता है. अगर यह पाथ ऐब्सलूट है, तो यह नियम किसी नॉन-हेरमेटिक Java रनटाइम को दिखाता है. साथ ही, यह रनटाइम के लिए भी एक जाना-पहचाना पाथ होता है. ऐसे में, srcs और java एट्रिब्यूट की वैल्यू सबमिट न करें.
lib_ct_sym	लेबल; None डिफ़ॉल्ट है --release के साथ कंपाइल करने के लिए, lib/ct.सिम फ़ाइल की ज़रूरत है. अगर इसके बारे में नहीं बताया गया है और srcs में सिर्फ़ एक ऐसी फ़ाइल है जिसका पाथ /lib/ct.sym पर खत्म होता है, तो उस फ़ाइल का इस्तेमाल किया जाता है.
lib_modules	लेबल; None डिफ़ॉल्ट है हर्मेटिक डिप्लॉयमेंट के लिए ज़रूरी lib/modules फ़ाइल.
output_licenses	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है
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_javacopts, compatible_with, deprecation, deps_checker, distribs, exec_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_for_tests, oneversion_whitelist, package_configuration, 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 लिंट को शुरू करते समय, JVM के लिए आर्ग्युमेंट की सूची.
android_lint_opts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है Android Lit आर्ग्युमेंट की सूची.
android_lint_package_configuration	लेबल की सूची; [] डिफ़ॉल्ट है Android लिंट कॉन्फ़िगरेशन, जिसे तय किए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
android_lint_runner	लेबल; None डिफ़ॉल्ट है Android लिंट रनर का लेबल, अगर कोई है.
bootclasspath	लेबल की सूची; [] डिफ़ॉल्ट है Java टारगेट बूटक्लासपाथ की एंट्री. javac के -bootclasspath फ़्लैग के साथ काम करता है.
compatible_javacopts	null; default is {} इंटरनल एपीआई, इसका इस्तेमाल न करें!
deps_checker	लेबल; None डिफ़ॉल्ट है इंपोर्ट DepsChecker का लेबल, जार को डिप्लॉय करता है.
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	लेबल की सूची; [] डिफ़ॉल्ट है java Builder_jvm_opts में लेबल-एक्सपंशन के लिए उपलब्ध डेटा लेबल.
javabuilder_jvm_opts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है JavaBuilder को शुरू करते समय, JVM के लिए आर्ग्युमेंट की सूची.
javac_supports_multiplex_workers	बूलियन; डिफ़ॉल्ट True है अगर JavaBuilder, मल्टीप्लेक्स पर लगातार चलने वाले वर्कर के तौर पर काम करता है, तो वैल्यू 'सही' होगी. अगर ऐसा नहीं है, तो 'गलत' है.
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_for_tests	लेबल; None डिफ़ॉल्ट है जांच के लिए एक वर्शन की अनुमति वाली सूची का लेबल.
oneversion_whitelist	लेबल; None डिफ़ॉल्ट है एक वर्शन की अनुमति वाली सूची का लेबल.
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	लेबल की सूची; [] डिफ़ॉल्ट है टर्बाइन_jvm_opts में लेबल-एक्सपंशन के लिए उपलब्ध डेटा लेबल.
turbine_jvm_opts	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है टर्बाइन को शुरू करते समय, जेवीएम के लिए तर्कों की सूची.
xlint	स्ट्रिंग की सूची; [] डिफ़ॉल्ट तौर पर सेट है डिफ़ॉल्ट सूची में जोड़ने या हटाने के लिए चेतावनी की सूची. इसके पहले डैश लगता है जिससे उसे हटा दिया जाता है. और जानकारी के लिए कृपया -Xlint विकल्पों पर Javac दस्तावेज़ देखें.