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

Java नियम

नियम

java_binary
java_Import
java_library
java_lite_proto_library
java_proto_library
java_test
java_package_config
java_plugins
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 संग्रह (जैर फ़ाइल) बनाता है. साथ ही, इस नाम के समान नाम वाली एक रैपर शेल स्क्रिप्ट भी बनाता है. रैपर शेल स्क्रिप्ट एक क्लासपाथ का इस्तेमाल करती है, जिसमें अन्य चीज़ों के अलावा, हर उस लाइब्रेरी के लिए एक जार फ़ाइल शामिल होती है, जिस पर बाइनरी निर्भर करती है.

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

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

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

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

अगर आपका टारगेट लॉन्चर एट्रिब्यूट तय करता है, तो सामान्य JAR फ़ाइल होने के बजाय _डिप्लॉयमेंट.js एक नेटिव बाइनरी होगा. इसमें लॉन्चर और साथ ही आपके नियम की सभी नेटिव (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`	`Name; required` इस टारगेट के लिए खास नाम. उस सोर्स फ़ाइल के नाम का इस्तेमाल करना अच्छा रहता है जो ऐप्लिकेशन का मुख्य एंट्री पॉइंट है (एक्सटेंशन को छोटा करके). उदाहरण के लिए, अगर आपके एंट्री पॉइंट को `Main.java` कहा जाता है, तो आपका नाम `Main` हो सकता है.
`deps`	`List of labels; optional` टारगेट में जोड़ी जाने वाली अन्य लाइब्रेरी की सूची. `deps` में सबसे ज़्यादा इस्तेमाल किए जाने वाले आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट के लिए तय की गई सामान्य विशेषताओं के बारे में सामान्य टिप्पणियां देखें.
`srcs`	`List of labels; optional` सोर्स फ़ाइलें जो टारगेट बनाने के लिए प्रोसेस की जाती हैं. यह एट्रिब्यूट करीब-करीब हमेशा ज़रूरी होता है. अपवाद नीचे देखें. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. अगर `.java` फ़ाइलें जनरेट की जाती हैं, तो आम तौर पर यह सुझाव दिया जाता है कि आप फ़ाइल के नाम के बजाय, जनरेट करने के नियम का नाम यहां डालें. ऐसा करने से, न सिर्फ़ आसानी से पढ़ा जा सकता है, बल्कि आने वाले समय में होने वाले बदलावों को भी आसानी से रोका जा सकता है: अगर जनरेट करने वाले नियम से, आने वाले समय में अलग-अलग फ़ाइलें जनरेट होती हैं, तो आपको सिर्फ़ एक जगह ठीक करना होगा: जनरेट करने वाले नियम का `outs`. आपको जनरेट करने वाले नियम को `deps` में शामिल नहीं करना चाहिए, क्योंकि ऐसा नहीं है. `.srcjar` टाइप की सोर्स फ़ाइलें अनपैक की गई हैं और कंपाइल की गई हैं. (यह तब काम आ सकता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो स्रोत फ़ाइल में बताए गए तरीके से उनका इस्तेमाल भी किया जाएगा. यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर किसी `main_class` एट्रिब्यूट से, रनटाइम क्लासपाथ में क्लास तय की जाती है या `runtime_deps` आर्ग्युमेंट को तय किया जाता है, तो यह आर्ग्युमेंट ज़रूरी है.
`resources`	`List of labels; optional` Java जार में शामिल करने के लिए, डेटा फ़ाइलों की सूची. अगर रिसॉर्स बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में संसाधनों का स्थान प्रोजेक्ट की संरचना से तय होता है. बेज़ल पहले मेवन के स्टैंडर्ड डायरेक्ट्री लेआउट, "src" डायरेक्ट्री के बाद, "resources" डायरेक्ट्री के पोते का पता ढूंढती है. अगर यह नहीं मिलता है, तो बाज़ल सबसे ऊपर "java" या "javatests" नाम की डायरेक्ट्री खोजता है. इसलिए, अगर संसाधन `<workspace root>/x/java/y/java/z` में है, तो रिसॉर्स का पाथ `y/java/z` होगा. इस अनुमान को बदला नहीं जा सकता; हालांकि, रिसॉर्स फ़ाइलों के लिए खास वैकल्पिक डायरेक्ट्री तय करने के लिए, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
`classpath_resources`	`List of labels; optional` इस विकल्प का इस्तेमाल तब तक न करें, जब तक यह किसी और तरीके से न हो) रिसॉर्स की ऐसी सूची जो जावा ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट का मकसद, सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी की मदद करना है जिनके लिए ज़रूरी है कि उनके संसाधन, क्लास पाथ पर `"myconfig.xml"` के तौर पर ढूंढे जाएं. नेमस्पेस की गड़बड़ी की वजह से, यह बदलाव सिर्फ़ बाइनरी फ़ाइलों पर लागू होता है.
`create_executable`	`Boolean; optional; nonconfigurable; default is True` बाइनरी फ़ाइल एक्ज़ीक्यूटेबल है या नहीं. एक्ज़ीक्यूटेबल ऐसी बाइनरी जो ट्रांज़िटिव रनटाइम डिपेंडेंसी को डिप्लॉयमेंट जार में इकट्ठा करती हैं. हालांकि, इसे सीधे एक्ज़ीक्यूट नहीं किया जा सकता. अगर यह विशेषता सेट की जाती है, तो कोई रैपर स्क्रिप्ट नहीं बनाई जाती. अगर `launcher` या `main_class` एट्रिब्यूट सेट हैं, तो इसे 0 पर सेट करना एक गड़बड़ी होती है.
`deploy_env`	`List of labels; optional` इस बाइनरी के लिए, डिप्लॉयमेंट एनवायरमेंट को दिखाने वाले अन्य `java_binary` टारगेट की सूची. इस प्लग इन को सेट करते समय, ऐसा प्लग इन बनाएं जो किसी दूसरे `java_binary` को लोड करेगा. इस एट्रिब्यूट को सेट करने पर, इस बाइनरी के रनटाइम क्लासपाथ और डिप्लॉयमेंट जार से सभी डिपेंडेंसी शामिल नहीं होती हैं. ये बाइनरी, बाइनरी और `deploy_env` में दिए गए टारगेट के बीच शेयर की जाती हैं.
`deploy_manifest_lines`	`List of strings; optional` `_deploy.jar` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ी जाने वाली लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट में "वैरिएबल बनाएं" विकल्प नहीं* होगा.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए अतिरिक्त कंपाइलर विकल्प. "वैरिएबल बनाएं" विकल्प के तहत और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद जावा में पास किए जाते हैं.
`jvm_flags`	`List of strings; optional` इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. $(location) और "Make वैरिएबल" के विकल्पों और बॉर्न शेल टोकनाइज़ेशन के मुताबिक. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल होती है (यह सभी डिपेंडेंट जार को ढूंढता है) और सही Java अनुवादक बनाता है. रैपर स्क्रिप्ट से जनरेट की जाने वाली कमांड लाइन में मुख्य क्लास का नाम और उसके बाद `"$@"` होता है, ताकि आप क्लासनेम के बाद अन्य आर्ग्युमेंट को पास कर सकें. हालांकि, JVM से पार्स करने के लिए ज़रूरी आर्ग्युमेंट को कमांड लाइन पर क्लास के नाम से पहले दिया जाना चाहिए. क्लास का नाम सूची में शामिल किए जाने से पहले, `jvm_flags` के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट से `_deploy.jar` आउटपुट पर कोई असर नहीं* पड़ता है.
`launcher`	`Label; optional` एक बाइनरी तय करें, जिसका इस्तेमाल JDK के साथ शामिल किए गए सामान्य `bin/java` प्रोग्राम के बजाय, आपके Java प्रोग्राम को चलाने के लिए किया जाएगा. टारगेट, `cc_binary` होना चाहिए. `cc_binary`, जो Java इनोवेशन एपीआई को लागू करता है उसे इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है. डिफ़ॉल्ट रूप से, 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` विशेषता है. इस मामले में, लिंकर को लगता है कि ऐसा कोड जिसकी वजह से बाइनरी फ़ाइल इस्तेमाल नहीं हुई है, उसे हटा दिया जाएगा. इसका मतलब है कि सिर्फ़ JNI से ऐक्सेस किए गए किसी भी C++ कोड को तब तक लिंक नहीं किया जा सकता, जब तक `cc_library` टारगेट में `alwayslink = 1` की जानकारी नहीं दी जाती. डिफ़ॉल्ट JDK लॉन्चर के अलावा, किसी भी लॉन्चर का इस्तेमाल करने पर, `*_deploy.jar` आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
`main_class`	`String; optional` एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, `main()` तरीके से क्लास का नाम. अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो इसे `srcs=[...]` सूची की ज़रूरत नहीं होती. इसलिए, इस एट्रिब्यूट का इस्तेमाल करके, ऐसी Java लाइब्रेरी से एक्ज़ीक्यूटेबल बनाया जा सकता है जिसमें पहले से ही एक या एक से ज़्यादा `main()` तरीके हैं. इस एट्रिब्यूट की वैल्यू कोई क्लास नाम है, सोर्स फ़ाइल नहीं. क्लास रनटाइम पर उपलब्ध होनी चाहिए; इसे इस नियम (`srcs` से) या सीधे तौर पर या ट्रांज़िटिव डिपेंडेंसी (`runtime_deps` या `deps` के ज़रिए) से कंपाइल किया जा सकता है. अगर क्लास उपलब्ध नहीं है, तो रनटाइम पर बाइनरी काम नहीं करेगी; बिल्ड-टाइम की कोई जांच नहीं है.
`plugins`	`List of labels; optional` कंपाइल के समय काम करने के लिए, Java कंपाइलर प्लग इन. इस नियम में बनाए गए हर `java_plugin` को इस नियम के बनाए जाने पर चलाया जाएगा. लाइब्रेरी में, `exported_plugins` का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लग इन लिया जा सकता है. प्लग इन से जनरेट हुए रिसॉर्स को इस नियम के नतीजे वाले जार में शामिल किया जाएगा.
`resource_jars`	`List of labels; optional` सुविधा बंद कर दी गई है: इसके बजाय, java_Import और Deps या रनटाइम_deps का इस्तेमाल करें.
`resource_strip_prefix`	`String; optional` Java रिसॉर्स से हटाने के लिए पाथ का प्रीफ़िक्स. अगर बताया गया हो, तो इस पाथ प्रीफ़िक्स को `resources` एट्रिब्यूट में मौजूद हर फ़ाइल से हटा दिया जाता है. किसी संसाधन फ़ाइल में यह गड़बड़ी है, जो इस डायरेक्ट्री में नहीं है. अगर इसके बारे में जानकारी (डिफ़ॉल्ट) नहीं दी जाती है, तो रिसॉर्स फ़ाइल का पाथ, उसी लॉजिक के हिसाब से तय किया जाता है जिसका इस्तेमाल सोर्स फ़ाइलों के Java पैकेज में किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद सोर्स फ़ाइल `foo/bar/a.txt` पर मौजूद होगी.
`runtime_deps`	`List of labels; optional` सिर्फ़ फ़ाइनल रनटाइम पर या टेस्ट के लिए उपलब्ध लाइब्रेरी. सामान्य `deps` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे, लेकिन कंपाइल-टाइम क्लास पाथ पर नहीं. सिर्फ़ रनटाइम के लिए ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को `runtime_deps` और `deps`, दोनों में दिखने वाले टारगेट को अनदेखा करना चाहिए.
`stamp`	`Integer; optional; default is -1` बिल्ड जानकारी को बाइनरी में एन्कोड करना है या नहीं. जितने तरह के प्लेसमेंट हो सकते हैं उनकी जानकारी यहां दी गई है: `stamp = 1`: `--nostamp` बिल्ड में हमेशा, बिल्ड की जानकारी को बाइनरी फ़ाइल में स्टैंप दें. इस सेटिंग से बचना चाहिए, क्योंकि इससे बाइनरी और इस पर निर्भर किसी भी डाउनस्ट्रीम कार्रवाई के लिए, रिमोट कैशिंग की सुविधा शायद खत्म हो जाए. `stamp = 0` बिल्ड की जानकारी को हमेशा कॉन्सटैंट वैल्यू से बदलें. इससे बिल्ड को कैश मेमोरी में सेव करने का अच्छा तरीका मिलता है. `stamp = -1`: बिल्ड की जानकारी एम्बेड करने की प्रक्रिया को `--[no]stamp` फ़्लैग से कंट्रोल किया जाता है. स्टैंपर की गई बाइनरी को तब तक फिर से नहीं बनाया जाता है, जब तक उनकी डिपेंडेंसी नहीं बदलती.
`use_launcher`	`Boolean; optional; default is True` क्या बाइनरी में कस्टम लॉन्चर का इस्तेमाल किया जाना चाहिए. अगर यह एट्रिब्यूट गलत पर सेट है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े `--java_launcher` फ़्लैग को इस टारगेट के लिए अनदेखा कर दिया जाएगा.
`use_testrunner`	`Boolean; optional; default is False` किसी Java प्रोग्राम के लिए, मुख्य एंट्री पॉइंट के तौर पर टेस्ट रनर (डिफ़ॉल्ट रूप से `com.google.testing.junit.runner.BazelTestRunner`) क्लास का इस्तेमाल करें. साथ ही, टेस्ट रनर को `bazel.test_suite` सिस्टम प्रॉपर्टी की वैल्यू के तौर पर टेस्ट क्लास उपलब्ध कराएं. आप इससे डिफ़ॉल्ट व्यवहार को बदल सकते हैं. इसका इस्तेमाल `java_test` नियमों के लिए टेस्ट रनर का इस्तेमाल करने और `java_binary` नियमों के लिए नहीं किया जा सकता. ऐसा लगता है कि आप ऐसा नहीं करना चाहेंगे. `AllTest` नियमों का इस्तेमाल एक ही ऐसे नियम के लिए होता है जिन्हें किसी अन्य नियम से शुरू किया जाता है (उदाहरण के लिए, जांच करने से पहले डेटाबेस को सेट अप करने के लिए). `AllTest` नियम को `java_binary` के तौर पर बताया जाना चाहिए. हालांकि, इसके लिए, टेस्ट रनर का इस्तेमाल मुख्य एंट्री पॉइंट के तौर पर किया जाना चाहिए. टेस्ट रनर क्लास का नाम, `main_class` एट्रिब्यूट से बदला जा सकता है.

java_Import

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

java_import(name, deps, data, 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`	`Name; required` इस टारगेट के लिए खास नाम.
`deps`	`List of labels; optional` टारगेट में जोड़ी जाने वाली अन्य लाइब्रेरी की सूची. java_library.deps देखें.
`constraints`	`List of strings; optional; nonconfigurable` इस नियम पर Java लाइब्रेरी के तौर पर लगाए गए अतिरिक्त कंस्ट्रेंट.
`exports`	`List of labels; optional` इस नियम के उपयोगकर्ताओं को उपलब्ध कराने के लिए टारगेट करता है. java_library.exports देखें.
`jars`	`List of labels; required` JAR फ़ाइलों की सूची, जो इस टारगेट पर निर्भर करने वाले Java टारगेट को देती हैं.
`neverlink`	`Boolean; optional; default is False` इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए करें, न कि रनटाइम के समय. यह तब काम आता है, जब लाइब्रेरी एक्ज़ीक्यूशन के दौरान रनटाइम एनवायरमेंट उपलब्ध कराए. इस तरह की लाइब्रेरी के उदाहरण हैं, IDE प्लग-इन के लिए IDE एपीआई या मानक JDK पर चल रहे किसी भी प्रोग्राम के लिए `tools.jar`.
`proguard_specs`	`List of labels; optional` ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इससे, ProGuard में इस्तेमाल किए जाने वाले स्पेसिफ़िकेशन के बारे में जानकारी मिलेगी. अगर जानकारी दी गई है, तो उसे इस लाइब्रेरी के आधार पर किसी भी `android_binary` टारगेट में जोड़ा जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ आसान नियम, जैसे कि -dontnote, -dontwarn, मान लेने वाले नुकसान, और -keep से शुरू होने वाले नियम होने चाहिए. दूसरे विकल्प, सिर्फ़ `android_binary` के proGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि वे ऑटोमैटिक मर्ज की प्रोसेस में शामिल न हों.
`runtime_deps`	`List of labels; optional` सिर्फ़ फ़ाइनल रनटाइम पर या टेस्ट के लिए उपलब्ध लाइब्रेरी. java_library.runtime_deps देखें.
`srcjar`	`Label; optional` यह एक ऐसी 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: सोर्स वाला एक संग्रह ("source java").

तर्क

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

Name; required

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

deps

List of labels; optional

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

Name; required

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

deps

List of labels; optional

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`	`Name; required` इस टारगेट के लिए खास नाम.
`deps`	`List of labels; optional` टारगेट में जोड़ी जाने वाली अन्य लाइब्रेरी की सूची. `deps` में सबसे ज़्यादा इस्तेमाल किए जाने वाले आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट के लिए तय की गई सामान्य विशेषताओं के बारे में सामान्य टिप्पणियां देखें.
`srcs`	`List of labels; optional` सोर्स फ़ाइलें जो टारगेट बनाने के लिए प्रोसेस की जाती हैं. यह एट्रिब्यूट करीब-करीब हमेशा ज़रूरी होता है. अपवाद नीचे देखें. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. अगर `.java` फ़ाइलें जनरेट की जाती हैं, तो आम तौर पर यह सुझाव दिया जाता है कि आप फ़ाइल के नाम के बजाय, जनरेट करने के नियम का नाम यहां डालें. ऐसा करने से, न सिर्फ़ आसानी से पढ़ा जा सकता है, बल्कि आने वाले समय में होने वाले बदलावों को भी आसानी से रोका जा सकता है: अगर जनरेट करने वाले नियम से, आने वाले समय में अलग-अलग फ़ाइलें जनरेट होती हैं, तो आपको सिर्फ़ एक जगह ठीक करना होगा: जनरेट करने वाले नियम का `outs`. आपको जनरेट करने वाले नियम को `deps` में शामिल नहीं करना चाहिए, क्योंकि ऐसा नहीं है. `.srcjar` टाइप की सोर्स फ़ाइलें अनपैक की गई हैं और कंपाइल की गई हैं. (यह तब काम आ सकता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो स्रोत फ़ाइल में बताए गए तरीके से उनका इस्तेमाल भी किया जाएगा. यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर किसी `main_class` एट्रिब्यूट से, रनटाइम क्लासपाथ में क्लास तय की जाती है या `runtime_deps` आर्ग्युमेंट को तय किया जाता है, तो यह आर्ग्युमेंट ज़रूरी है.
`resources`	`List of labels; optional` Java जार में शामिल करने के लिए, डेटा फ़ाइलों की सूची. अगर रिसॉर्स बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में संसाधनों का स्थान प्रोजेक्ट की संरचना से तय होता है. बेज़ल पहले मेवन के स्टैंडर्ड डायरेक्ट्री लेआउट, "src" डायरेक्ट्री के बाद, "resources" डायरेक्ट्री के पोते का पता ढूंढती है. अगर यह नहीं मिलता है, तो बाज़ल सबसे ऊपर "java" या "javatests" नाम की डायरेक्ट्री खोजता है. इसलिए, अगर संसाधन `<workspace root>/x/java/y/java/z` में है, तो रिसॉर्स का पाथ `y/java/z` होगा. इस अनुमान को बदला नहीं जा सकता; हालांकि, रिसॉर्स फ़ाइलों के लिए खास वैकल्पिक डायरेक्ट्री तय करने के लिए, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
`classpath_resources`	`List of labels; optional` इस विकल्प का इस्तेमाल तब तक न करें, जब तक यह किसी और तरीके से न हो) रिसॉर्स की ऐसी सूची जो जावा ट्री के रूट में मौजूद होनी चाहिए. इस एट्रिब्यूट का मकसद, सिर्फ़ तीसरे पक्ष की उन लाइब्रेरी की मदद करना है जिनके लिए ज़रूरी है कि उनके संसाधन, क्लास पाथ पर `"myconfig.xml"` के तौर पर ढूंढे जाएं. नेमस्पेस की गड़बड़ी की वजह से, यह बदलाव सिर्फ़ बाइनरी फ़ाइलों पर लागू होता है.
`create_executable`	`Boolean; optional; nonconfigurable; default is True` बाइनरी फ़ाइल एक्ज़ीक्यूटेबल है या नहीं. एक्ज़ीक्यूटेबल ऐसी बाइनरी जो ट्रांज़िटिव रनटाइम डिपेंडेंसी को डिप्लॉयमेंट जार में इकट्ठा करती हैं. हालांकि, इसे सीधे एक्ज़ीक्यूट नहीं किया जा सकता. अगर यह विशेषता सेट की जाती है, तो कोई रैपर स्क्रिप्ट नहीं बनाई जाती. अगर `launcher` या `main_class` एट्रिब्यूट सेट हैं, तो इसे 0 पर सेट करना एक गड़बड़ी होती है.
`deploy_manifest_lines`	`List of strings; optional` `_deploy.jar` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ी जाने वाली लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट में "वैरिएबल बनाएं" विकल्प नहीं* होगा.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए अतिरिक्त कंपाइलर विकल्प. "वैरिएबल बनाएं" विकल्प के तहत और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद जावा में पास किए जाते हैं.
`jvm_flags`	`List of strings; optional` इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. $(location) और "Make वैरिएबल" के विकल्पों और बॉर्न शेल टोकनाइज़ेशन के मुताबिक. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल होती है (यह सभी डिपेंडेंट जार को ढूंढता है) और सही Java अनुवादक बनाता है. रैपर स्क्रिप्ट से जनरेट की जाने वाली कमांड लाइन में मुख्य क्लास का नाम और उसके बाद `"$@"` होता है, ताकि आप क्लासनेम के बाद अन्य आर्ग्युमेंट को पास कर सकें. हालांकि, JVM से पार्स करने के लिए ज़रूरी आर्ग्युमेंट को कमांड लाइन पर क्लास के नाम से पहले दिया जाना चाहिए. क्लास का नाम सूची में शामिल किए जाने से पहले, `jvm_flags` के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट से `_deploy.jar` आउटपुट पर कोई असर नहीं* पड़ता है.
`launcher`	`Label; optional` एक बाइनरी तय करें, जिसका इस्तेमाल JDK के साथ शामिल किए गए सामान्य `bin/java` प्रोग्राम के बजाय, आपके Java प्रोग्राम को चलाने के लिए किया जाएगा. टारगेट, `cc_binary` होना चाहिए. `cc_binary`, जो Java इनोवेशन एपीआई को लागू करता है उसे इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है. डिफ़ॉल्ट रूप से, 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` विशेषता है. इस मामले में, लिंकर को लगता है कि ऐसा कोड जिसकी वजह से बाइनरी फ़ाइल इस्तेमाल नहीं हुई है, उसे हटा दिया जाएगा. इसका मतलब है कि सिर्फ़ JNI से ऐक्सेस किए गए किसी भी C++ कोड को तब तक लिंक नहीं किया जा सकता, जब तक `cc_library` टारगेट में `alwayslink = 1` की जानकारी नहीं दी जाती. डिफ़ॉल्ट JDK लॉन्चर के अलावा, किसी भी लॉन्चर का इस्तेमाल करने पर, `*_deploy.jar` आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
`main_class`	`String; optional` एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, `main()` तरीके से क्लास का नाम. अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो इसे `srcs=[...]` सूची की ज़रूरत नहीं होती. इसलिए, इस एट्रिब्यूट का इस्तेमाल करके, ऐसी Java लाइब्रेरी से एक्ज़ीक्यूटेबल बनाया जा सकता है जिसमें पहले से ही एक या एक से ज़्यादा `main()` तरीके हैं. इस एट्रिब्यूट की वैल्यू कोई क्लास नाम है, सोर्स फ़ाइल नहीं. क्लास रनटाइम पर उपलब्ध होनी चाहिए; इसे इस नियम (`srcs` से) या सीधे तौर पर या ट्रांज़िटिव डिपेंडेंसी (`runtime_deps` या `deps` के ज़रिए) से कंपाइल किया जा सकता है. अगर क्लास उपलब्ध नहीं है, तो रनटाइम पर बाइनरी काम नहीं करेगी; बिल्ड-टाइम की कोई जांच नहीं है.
`plugins`	`List of labels; optional` कंपाइल के समय काम करने के लिए, Java कंपाइलर प्लग इन. इस नियम में बनाए गए हर `java_plugin` को इस नियम के बनाए जाने पर चलाया जाएगा. लाइब्रेरी में, `exported_plugins` का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लग इन लिया जा सकता है. प्लग इन से जनरेट हुए रिसॉर्स को इस नियम के नतीजे वाले जार में शामिल किया जाएगा.
`resource_jars`	`List of labels; optional` सुविधा बंद कर दी गई है: इसके बजाय, java_Import और Deps या रनटाइम_deps का इस्तेमाल करें.
`resource_strip_prefix`	`String; optional` Java रिसॉर्स से हटाने के लिए पाथ का प्रीफ़िक्स. अगर बताया गया हो, तो इस पाथ प्रीफ़िक्स को `resources` एट्रिब्यूट में मौजूद हर फ़ाइल से हटा दिया जाता है. किसी संसाधन फ़ाइल में यह गड़बड़ी है, जो इस डायरेक्ट्री में नहीं है. अगर इसके बारे में जानकारी (डिफ़ॉल्ट) नहीं दी जाती है, तो रिसॉर्स फ़ाइल का पाथ, उसी लॉजिक के हिसाब से तय किया जाता है जिसका इस्तेमाल सोर्स फ़ाइलों के Java पैकेज में किया जाता है. उदाहरण के लिए, `stuff/java/foo/bar/a.txt` पर मौजूद सोर्स फ़ाइल `foo/bar/a.txt` पर मौजूद होगी.
`runtime_deps`	`List of labels; optional` सिर्फ़ फ़ाइनल रनटाइम पर या टेस्ट के लिए उपलब्ध लाइब्रेरी. सामान्य `deps` की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे, लेकिन कंपाइल-टाइम क्लास पाथ पर नहीं. सिर्फ़ रनटाइम के लिए ज़रूरी डिपेंडेंसी यहां दी जानी चाहिए. डिपेंडेंसी-विश्लेषण टूल को `runtime_deps` और `deps`, दोनों में दिखने वाले टारगेट को अनदेखा करना चाहिए.
`stamp`	`Integer; optional; default is 0` बिल्ड जानकारी को बाइनरी में एन्कोड करना है या नहीं. जितने तरह के प्लेसमेंट हो सकते हैं उनकी जानकारी यहां दी गई है: `stamp = 1`: `--nostamp` बिल्ड में हमेशा, बिल्ड की जानकारी को बाइनरी फ़ाइल में स्टैंप दें. इस सेटिंग से बचना चाहिए, क्योंकि इससे बाइनरी और इस पर निर्भर किसी भी डाउनस्ट्रीम कार्रवाई के लिए, रिमोट कैशिंग की सुविधा शायद खत्म हो जाए. `stamp = 0` बिल्ड की जानकारी को हमेशा कॉन्सटैंट वैल्यू से बदलें. इससे बिल्ड को कैश मेमोरी में सेव करने का अच्छा तरीका मिलता है. `stamp = -1`: बिल्ड की जानकारी एम्बेड करने की प्रक्रिया को `--[no]stamp` फ़्लैग से कंट्रोल किया जाता है. स्टैंपर की गई बाइनरी को तब तक फिर से नहीं बनाया जाता है, जब तक उनकी डिपेंडेंसी नहीं बदलती.
`test_class`	`String; optional` टेस्ट रनर से लोड किया गया Java क्लास. डिफ़ॉल्ट रूप से, अगर इस आर्ग्युमेंट को तय नहीं किया गया है, तो लेगसी मोड का इस्तेमाल किया जाता है. पहले तर्क पर, `--nolegacy_bazel_java_test` फ़्लैग को फ़ॉलबैक पर सेट न करें. यह एट्रिब्यूट उस Java क्लास का नाम बताता है जिसे इस टेस्ट में चलाया जाना है. इसे सेट करना बहुत कम होता है. अगर यह आर्ग्युमेंट हटाया जाता है, तो इसका अनुमान टारगेट के `name` और उसके सोर्स-रिलेटिव पाथ का इस्तेमाल करके लगाया जाएगा. अगर टेस्ट जानी-पहचानी सोर्स की रूट के बाहर मौजूद है, तो Bazel एक गड़बड़ी रिपोर्ट करेगा. ऐसा तब होगा, जब `test_class` को सेट नहीं किया गया हो. 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`	`Boolean; optional; default is True` क्या बाइनरी में कस्टम लॉन्चर का इस्तेमाल किया जाना चाहिए. अगर यह एट्रिब्यूट गलत पर सेट है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े `--java_launcher` फ़्लैग को इस टारगेट के लिए अनदेखा कर दिया जाएगा.
`use_testrunner`	`Boolean; optional; default is True` किसी Java प्रोग्राम के लिए, मुख्य एंट्री पॉइंट के तौर पर टेस्ट रनर (डिफ़ॉल्ट रूप से `com.google.testing.junit.runner.BazelTestRunner`) क्लास का इस्तेमाल करें. साथ ही, टेस्ट रनर को `bazel.test_suite` सिस्टम प्रॉपर्टी की वैल्यू के तौर पर टेस्ट क्लास उपलब्ध कराएं. आप इससे डिफ़ॉल्ट व्यवहार को बदल सकते हैं. इसका इस्तेमाल `java_test` नियमों के लिए टेस्ट रनर का इस्तेमाल करने और `java_binary` नियमों के लिए नहीं किया जा सकता. ऐसा लगता है कि आप ऐसा नहीं करना चाहेंगे. `AllTest` नियमों का इस्तेमाल एक ही ऐसे नियम के लिए होता है जिन्हें किसी अन्य नियम से शुरू किया जाता है (उदाहरण के लिए, जांच करने से पहले डेटाबेस को सेट अप करने के लिए). `AllTest` नियम को `java_binary` के तौर पर बताया जाना चाहिए. हालांकि, इसके लिए, टेस्ट रनर का इस्तेमाल मुख्य एंट्री पॉइंट के तौर पर किया जाना चाहिए. टेस्ट रनर क्लास का नाम, `main_class` एट्रिब्यूट से बदला जा सकता है.

java_package_config

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

java_package_configuration(name, data, compatible_with, deprecation, distribs, features, javacopts, licenses, packages, restricted_to, tags, target_compatible_with, testonly, 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`	`Name; required` इस टारगेट के लिए खास नाम.
`data`	`List of labels; optional` रनटाइम के दौरान, इस कॉन्फ़िगरेशन के लिए ज़रूरी फ़ाइलों की सूची.
`javacopts`	`List of strings; optional` Java कंपाइलर फ़्लैग.
`packages`	`List of labels; optional` `package_group` के सेट पर कॉन्फ़िगरेशन लागू किया जाना चाहिए.

java_plugins

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

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 कंपाइलर के लिए प्लग इन बताता है. इस समय, व्याख्या करने की सुविधा सिर्फ़ एक तरह के प्लग इन के साथ काम करती है. प्लग इन के हिसाब से, plugins एट्रिब्यूट इस्तेमाल करके, java_library या java_binary का नियम लागू हो सकता है. java_library, प्लग इन को उन लाइब्रेरी में भी अपने-आप एक्सपोर्ट कर सकता है जो exported_plugins का इस्तेमाल करके, सीधे उस पर निर्भर करती हैं.

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

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

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

तर्क

विशेषताएं
`name`	`Name; required` इस टारगेट के लिए खास नाम.
`deps`	`List of labels; optional` इस लाइब्रेरी में जोड़ी जाने वाली लाइब्रेरी की सूची. `deps` में सबसे ज़्यादा इस्तेमाल किए जाने वाले आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट के लिए तय की गई सामान्य विशेषताओं के बारे में सामान्य टिप्पणियां देखें. `deps` में दिए गए `java_library` नियमों से बनाए गए जार, इस नियम के कंपाइल होने में लगने वाले क्लास पाथ पर होंगे. इसके अलावा, अपने `deps`, `runtime_deps`, और `exports` को ट्रांज़िट समय में बंद कर दिया जाएगा और रनटाइम क्लास पाथ का इस्तेमाल किया जाएगा. इसके उलट, `data` एट्रिब्यूट के टारगेट, रनफ़ाइल में शामिल किए जाते हैं. हालांकि, कंपाइल-टाइम या रनटाइम क्लास पाथ में ये शामिल नहीं होते.
`srcs`	`List of labels; optional` सोर्स फ़ाइलें जो टारगेट बनाने के लिए प्रोसेस की जाती हैं. यह एट्रिब्यूट करीब-करीब हमेशा ज़रूरी होता है. अपवाद नीचे देखें. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. अगर `.java` फ़ाइलें जनरेट की जाती हैं, तो आम तौर पर यह सुझाव दिया जाता है कि आप फ़ाइल के नाम के बजाय, जनरेट करने के नियम का नाम यहां डालें. ऐसा करने से, न सिर्फ़ आसानी से पढ़ा जा सकता है, बल्कि आने वाले समय में होने वाले बदलावों को भी आसानी से रोका जा सकता है: अगर जनरेट करने वाले नियम से, आने वाले समय में अलग-अलग फ़ाइलें जनरेट होती हैं, तो आपको सिर्फ़ एक जगह ठीक करना होगा: जनरेट करने वाले नियम का `outs`. आपको जनरेट करने वाले नियम को `deps` में शामिल नहीं करना चाहिए, क्योंकि ऐसा नहीं है. `.srcjar` टाइप की सोर्स फ़ाइलें अनपैक की गई हैं और कंपाइल की गई हैं. (यह तब काम आ सकता है, जब आपको genrule की मदद से `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो स्रोत फ़ाइल में बताए गए तरीके से उनका इस्तेमाल भी किया जाएगा. यह आर्ग्युमेंट हमेशा ज़रूरी होता है. हालांकि, अगर किसी `main_class` एट्रिब्यूट से, रनटाइम क्लासपाथ में क्लास तय की जाती है या `runtime_deps` आर्ग्युमेंट को तय किया जाता है, तो यह आर्ग्युमेंट ज़रूरी है.
`data`	`List of labels; optional` रनटाइम के दौरान, इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. `data` में सबसे ज़्यादा इस्तेमाल किए जाने वाले आम तौर पर इस्तेमाल होने वाले एट्रिब्यूट के लिए तय की गई सामान्य विशेषताओं के बारे में सामान्य टिप्पणियां देखें. `java_library` बनाते समय, Bazel इन फ़ाइलों को कहीं नहीं रखता. अगर `data` फ़ाइलें जनरेट की जाती हैं, तो Bazel उन्हें जनरेट करता है. कोई ऐसा टेस्ट बनाते समय जो `java_library` Bazel पर निर्भर होता है या फिर `data` फ़ाइलों को रनफ़ाइल एरिया में लिंक करता है.
`resources`	`List of labels; optional` Java जार में शामिल करने के लिए, डेटा फ़ाइलों की सूची. अगर रिसॉर्स बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में संसाधनों का स्थान प्रोजेक्ट की संरचना से तय होता है. बेज़ल पहले मेवन के स्टैंडर्ड डायरेक्ट्री लेआउट, "src" डायरेक्ट्री के बाद, "resources" डायरेक्ट्री के पोते का पता ढूंढती है. अगर यह नहीं मिलता है, तो बाज़ल सबसे ऊपर "java" या "javatests" नाम की डायरेक्ट्री खोजता है. इसलिए, अगर संसाधन `<workspace root>/x/java/y/java/z` में है, तो रिसॉर्स का पाथ `y/java/z` होगा. इस अनुमान को बदला नहीं जा सकता; हालांकि, रिसॉर्स फ़ाइलों के लिए खास वैकल्पिक डायरेक्ट्री तय करने के लिए, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं.
`generates_api`	`Boolean; optional; default is False` यह एट्रिब्यूट, एपीआई प्रोसेस जनरेट करने वाले एनोटेशन प्रोसेसर को मार्क करता है. अगर कोई नियम, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो अन्य नियम, इस बात पर निर्भर करते हैं कि जनरेट किए गए कोड का रेफ़रंस सिर्फ़ तब दिया जा सकता है, जब कंपाइल करने की कार्रवाइयां, जनरेट होने वाले नियम के बाद शेड्यूल की गई हों. इस विशेषता का इस्तेमाल करके, Bazel को यह निर्देश दिया जाता है कि वह java_header_compilation के चालू होने पर, शेड्यूल करने से जुड़े प्रतिबंध लागू करे. चेतावनी: बिल्ड परफ़ॉर्मेंस पर इस एट्रिब्यूट का असर पड़ता है. ज़रूरत पड़ने पर ही इसका इस्तेमाल करें.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए अतिरिक्त कंपाइलर विकल्प. "वैरिएबल बनाएं" विकल्प के तहत और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करता है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद जावा में पास किए जाते हैं.
`neverlink`	`Boolean; optional; default is False` क्या इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए, न कि रनटाइम के समय. यह तब काम आता है, जब लाइब्रेरी एक्ज़ीक्यूशन के दौरान रनटाइम एनवायरमेंट में देती हो. स्टैंडर्ड लाइब्रेरी पर चलने वाले किसी भी कोड के लिए, इस तरह की लाइब्रेरी के आईडीई एपीआई `tools.jar` होते हैं. ध्यान दें कि `neverlink = 1` कंपाइलर को उस लाइब्रेरी पर मौजूद कॉन्टेंट को इनलाइन करने से नहीं रोकता है जो इस बात पर निर्भर करता है कि वह उस प्रोजेक्ट पर निर्भर है, जैसा कि Java लैंग्वेज स्पेसिफ़िकेशन में बताई गई अनुमति है. `static final`, `String` या प्रिमिटिव टाइप के कॉन्सटेंट हैं). इसलिए, इस्तेमाल का मुख्य उदाहरण तब दिया जाता है, जब रनटाइम लाइब्रेरी और कंप्यूशन लाइब्रेरी, दोनों एक जैसी होती हैं. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि वह सिर्फ़ उन जगहों पर अलग हो जहां जेएलएस कंपाइलर को इनलाइन में आने से रोकती है (या जेएलएस के आने वाले सभी वर्शन के लिए होल्ड होनी चाहिए).
`output_licenses`	`Licence type; optional` `common attributes` देखें
`plugins`	`List of labels; optional` कंपाइल के समय काम करने के लिए, Java कंपाइलर प्लग इन. इस नियम में बनाए गए हर `java_plugin` को इस नियम के बनाए जाने पर चलाया जाएगा. लाइब्रेरी में, `exported_plugins` का इस्तेमाल करने वाली डिपेंडेंसी से भी प्लग इन लिया जा सकता है. प्लग इन से जनरेट हुए रिसॉर्स को इस नियम के नतीजे वाले जार में शामिल किया जाएगा.
`processor_class`	`String; optional` प्रोसेसर क्लास पूरी तरह से उस क्लास का टाइप है जो Java कंपाइलर को एनोटेशन प्रोसेसर में एंट्री पॉइंट के तौर पर इस्तेमाल करना चाहिए. अगर इस नीति के बारे में जानकारी नहीं दी गई है, तो इस नियम में Java कंपाइलर की एनोटेशन प्रोसेसिंग में योगदान नहीं दिया जाएगा. हालांकि, इसके रनटाइम क्लासपाथ को कंपाइलर के एनोटेशन प्रोसेसर पाथ में शामिल किया जाएगा. (इसे मुख्य रूप से गड़बड़ी की संभावना वाले प्लग इन के इस्तेमाल के लिए बनाया जाता है. इन्हें java.util.ServiceLoader का इस्तेमाल करके, एनोटेशन प्रोसेसर पाथ से लोड किया जाता है.)
`proguard_specs`	`List of labels; optional` ProGuard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इससे, ProGuard में इस्तेमाल किए जाने वाले स्पेसिफ़िकेशन के बारे में जानकारी मिलेगी. अगर जानकारी दी गई है, तो उसे इस लाइब्रेरी के आधार पर किसी भी `android_binary` टारगेट में जोड़ा जाएगा. यहां शामिल की गई फ़ाइलों में सिर्फ़ आसान नियम, जैसे कि -dontnote, -dontwarn, मान लेने वाले नुकसान, और -keep से शुरू होने वाले नियम होने चाहिए. दूसरे विकल्प, सिर्फ़ `android_binary` के proGuard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि वे ऑटोमैटिक मर्ज की प्रोसेस में शामिल न हों.
`resource_jars`	`List of labels; optional` सुविधा बंद कर दी गई है: इसके बजाय, java_Import और Deps या रनटाइम_deps का इस्तेमाल करें.
`resource_strip_prefix`	`String; optional` 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_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`	`Name; required` इस टारगेट के लिए खास नाम.
`srcs`	`List of labels; optional` रनटाइम में मौजूद सभी फ़ाइलें.
`default_cds`	`Label; optional` हर्मेटिक `java_runtime` के लिए डिफ़ॉल्ट सीडीएस संग्रह. जब `java_binary` टारगेट के लिए हर्मेटिक को चालू किया जाता है और अगर टारगेट, `classlist` एट्रिब्यूट को तय करके अपना खुद का सीडीएस संग्रह नहीं देता है, तो `java_runtime` डिफ़ॉल्ट सीडीएस को इंटरनल डिप्लॉयमेंट जेएआर में पैकेज किया जाता है.
`hermetic_srcs`	`List of labels; optional` हर्मेटिक डिप्लॉयमेंट के लिए रनटाइम में ज़रूरी फ़ाइलें.
`java`	`Label; optional` Java एक्ज़ीक्यूटेबल का पाथ.
`java_home`	`String; optional` रनटाइम के रूट का पाथ. "मेक" वैरिएबल के विकल्प के तहत. अगर यह पाथ सटीक है, तो नियम यह बताता है कि एक मशहूर पाथ के साथ एक नॉन-हेरमेटिक Java रनटाइम दिख रहा है. ऐसे में, `srcs` और `java` एट्रिब्यूट की वैल्यू खाली होनी चाहिए.
`lib_modules`	`Label; optional` लिमेट/मॉड्यूल फ़ाइल, जो हर महीने डिप्लॉयमेंट के लिए ज़रूरी है.
`version`	`Integer; optional; default is 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_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`	`Name; required` इस टारगेट के लिए खास नाम.
`android_lint_data`	`List of labels; optional` android_lint_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध टूल के लेबल.
`android_lint_jvm_opts`	`List of strings; optional` Android लिंट का इस्तेमाल करते समय, जेवीएम के लिए आर्ग्युमेंट की सूची.
`android_lint_opts`	`List of strings; optional` Android लिंट आर्ग्युमेंट की सूची.
`android_lint_package_configuration`	`List of labels; optional` Android लिंट कॉन्फ़िगरेशन, जिसे तय किए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
`android_lint_runner`	`Label; optional` Android लिंट रनर का लेबल, अगर कोई हो.
`bootclasspath`	`List of labels; optional` Java टारगेट बूटक्लास पाथ एंट्री. javac के -bootclasspath फ़्लैग के मुताबिक.
`deps_checker`	`List of labels; optional` ImportDepsChecker डिप्लॉयमेंट जार का लेबल.
`forcibly_disable_header_compilation`	`Boolean; optional; default is False` यह उन डिवाइस पर हेडर कंपाइलेशन को बंद करने के लिए --java_header_compilation को ओवरराइड करता है, जो इस पर काम नहीं करते. उदाहरण के लिए, JDK 7 Bazel.
`genclass`	`List of labels; required` GenClass डिप्लॉय करने वाले जार का लेबल.
`header_compiler`	`List of labels; optional` हेडर कंपाइलर का लेबल. अगर --java_header_compilation चालू है, तो ज़रूरी है.
`header_compiler_direct`	`List of labels; optional` हेडर कंपाइलर का वैकल्पिक लेबल, ताकि डायरेक्ट क्लास की उन कार्रवाइयों के लिए इस्तेमाल किया जा सके जिनमें एपीआई जनरेट करने वाला कोई भी एनोटेशन प्रोसेसर शामिल न हो. इस टूल पर एनोटेशन प्रोसेसिंग की सुविधा नहीं है.
`ijar`	`List of labels; required` लागू करने के लिए इज़र लेबल का लेबल.
`jacocorunner`	`Label; optional` जैकोकोकवरेज रनर का लेबल, जार डिप्लॉय करता है.
`java_runtime`	`Label; required` इस टूलचेन के साथ इस्तेमाल करने के लिए java_runtime. यह डिफ़ॉल्ट तौर पर, एक्ज़ीक्यूशन कॉन्फ़िगरेशन में java_runtime है.
`javabuilder`	`List of labels; required` JavaBuilder डिप्लॉयमेंट जार का लेबल.
`javabuilder_data`	`List of labels; optional` javabuilder_jvm_opts के लिए लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
`javabuilder_jvm_opts`	`List of strings; optional` JavaBuilder का इस्तेमाल करने के दौरान, जेवीएम के लिए आर्ग्युमेंट की सूची.
`javac_supports_multiplex_workers`	`Boolean; optional; default is True` अगर JavaBuilder, मल्टीप्लेक्स परसिस्टेंट वर्कर के तौर पर चलने की सुविधा देता है, तो यह सही होता है. ऐसा नहीं होता है, तो ऐसा 'गलत' के तौर पर होता है.
`javac_supports_workers`	`Boolean; optional; default is True` अगर Javaबिल्डर एक स्थायी वर्कर के तौर पर चलने की सुविधा देता है, तो यह सही होता है, अगर ऐसा नहीं होता है, तो सही होता है.
`javacopts`	`List of strings; optional` Java कंपाइलर के लिए अतिरिक्त आर्ग्युमेंट की सूची. संभावित Java कंपाइलर फ़्लैग की बड़ी सूची देखने के लिए, कृपया Java कंपाइलर दस्तावेज़ देखें.
`jvm_opts`	`List of strings; optional` Java कंपाइलर का इस्तेमाल करते समय, जेवीएम के लिए आर्ग्युमेंट की सूची. इस विकल्प के लिए, फ़्लैग किए गए कई संभावित फ़्लैग की सूची देखने के लिए, कृपया Java वर्चुअल मशीन के दस्तावेज़ देखें.
`oneversion`	`Label; optional` एक-वर्शन वाली बाइनरी का लेबल.
`oneversion_whitelist`	`Label; optional` एक संस्करण वाली व्हाइटलिस्ट का लेबल.
`package_configuration`	`List of labels; optional` कॉन्फ़िगरेशन, जिसे बताए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
`proguard_allowlister`	`Label; optional; default is @bazel_tools//tools/jdk:proguard_whitelister` ProGuard अनुमति देने वाली कंपनी का लेबल.
`resourcejar`	`List of labels; optional` रिसॉर्स जार बिल्डर एक्ज़ीक्यूटेबल का लेबल.
`singlejar`	`List of labels; required` सिंगलजर डिप्लॉयमेंट जार का लेबल.
`source_version`	`String; optional` Java सोर्स वर्शन (उदाहरण, '6' या '7'). इससे पता चलता है कि Java सोर्स कोड में, कोड स्ट्रक्चर के किस सेट की अनुमति है.
`target_version`	`String; optional` Java टारगेट वर्शन (उदाहरण के लिए, '6' या '7'). इससे पता चलता है कि क्लास को किस Java रनटाइम के लिए बनाया जाना चाहिए.
`timezone_data`	`Label; optional` ऐसे रिसॉर्स के लेबल का लेबल जिसमें समय क्षेत्र का डेटा शामिल है. अगर इस नीति को सेट किया जाता है, तो समय क्षेत्र का डेटा, सभी java_binary नियमों की इंप्लिसिट रनटाइम डिपेंडेंसी के तौर पर जोड़ा जाता है.
`tools`	`List of labels; optional` jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध टूल के लेबल.
`turbine_data`	`List of labels; optional` turbine_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
`turbine_jvm_opts`	`List of strings; optional` टर्बाइन की शुरुआत करते समय, जेवीएम के लिए आर्ग्युमेंट की सूची.
`xlint`	`List of strings; optional` डिफ़ॉल्ट सूची में चेतावनी जोड़ने या उससे हटाने के लिए चेतावनी की सूची. इसके पहले डैश का इस्तेमाल करके इसे हटाया जाता है. ज़्यादा जानकारी के लिए, कृपया -Xlint विकल्पों पर Javac दस्तावेज़ देखें.