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

Java नियम

नियम

java_binary
java_import
java_library
java_lite_proto_library
java_proto_library
java_test
java_package_config
java_प्लग इन
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 संग्रह ("jam file&kot;) बनाता है, साथ ही नियम के समान नाम वाली एक रैपर शेल स्क्रिप्ट बनाता है. रैपर शेल स्क्रिप्ट में किसी क्लासपाथ का इस्तेमाल होता है, जिसमें दूसरी लाइब्रेरी के साथ-साथ, हर उस लाइब्रेरी के लिए एक जार फ़ाइल इस्तेमाल होती है जिस पर बाइनरी निर्भर करती है.

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

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

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

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

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

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

नीचे दिया गया कोड स्निपेट एक आम गलती को दिखाता है:

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

इसके बजाय, यह करें:

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

तर्क

एट्रिब्यूट
`name`	`Name; required` इस टारगेट का एक यूनीक नाम. ऐप्लिकेशन का मुख्य एंट्री पॉइंट जिस सोर्स फ़ाइल का है, उसके नाम का इस्तेमाल करना बेहतर होता है. उदाहरण के लिए, अगर आपके एंट्री पॉइंट को `Main.java` कहा जाता है, तो आपका नाम `Main` हो सकता है.
`deps`	`List of labels; optional` टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. `deps` के बारे में सामान्य टिप्पणियां देखें, जो सबसे ज़्यादा बनाए गए नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट पर मौजूद हैं.
`srcs`	`List of labels; optional` उन सोर्स फ़ाइलों की सूची जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. इस एट्रिब्यूट की ज़रूरत करीब-करीब हमेशा होती है. अपवाद के बारे में नीचे जानकारी दें. `.java` टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई `.java` फ़ाइलों के मामले में, फ़ाइल को नाम देने के बजाय, आम तौर पर जनरेट किए जाने वाले नियम' का नाम यहां डालने की सलाह दी जाती है. इससे, आने वाले समय में होने वाले बदलावों पर भी आसानी से असर पड़ता है. हालांकि, अगर आने वाले समय में जनरेट करने वाला नियम अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह की जांच करनी होगी: जनरेट करने के नियम का `outs`. आपको जनरेट करने वाले नियम को `deps` में शामिल नहीं करना चाहिए, क्योंकि यह काम नहीं करता है. `.srcjar` तरह की सोर्स फ़ाइलें पैक नहीं की जाती और कंपाइल की जाती हैं. (इसका इस्तेमाल तब किया जा सकता है, जब आपको जनरेट करने के लिए बिना किसी नियम वाली `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई फ़ाइलों में से किसी भी फ़ाइल को जनरेट करता है, तो सोर्स फ़ाइल की तरह ही उनका इस्तेमाल किया जाएगा. इस आर्ग्युमेंट की हमेशा ज़रूरत होती है. हालांकि, `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर क्लास के बारे में बताता है या `runtime_deps` आर्ग्युमेंट के बारे में बताता है.
`resources`	`List of labels; optional` Java जार में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधन बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में मौजूद संसाधनों की जगह, प्रोजेक्ट के हिसाब से तय की जाती है. बेज़ेल पहले Maven' के स्टैंडर्ड डायरेक्ट्री लेआउट, (a &quat;src&kot; डायरेक्ट्री के बाद एक "resources&quat; डायरेक्ट्री ग्रैंड चाइल्ड) ढूंढते हैं. अगर उसे नहीं मिलता है, तो बेज़ेल फिर "java&quat; या &quat;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` बाइनरी फ़ाइल एक्ज़ीक्यूटेबल है या नहीं. एक्ज़ीक्यूटेबल बाइनरी, ट्रांज़िशन वाले Java Java की डिपेंडेंसी को डिप्लॉयमेंट जार में इकट्ठा करती हैं. हालांकि, उन्हें सीधे तौर पर लागू नहीं किया जा सकता. अगर इस एट्रिब्यूट को सेट किया जाता है, तो कोई रैपर स्क्रिप्ट नहीं बनाई जाती. अगर `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` फ़ाइल में जोड़ी जाने वाली लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट को नहीं* "वैरिएबल बनाएं</br>; की जगह लागू करें.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए अतिरिक्त कंपाइलर विकल्प. &quat;वैरिएबल वैरिएबल&कोटेशन के विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद Javac को पास किए जाते हैं.
`jvm_flags`	`List of strings; optional` इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में जोड़ने के लिए फ़्लैग की सूची. $(location) और &quat;वैरिएबल वैरिएबल</ot> के विकल्प के साथ-साथ, बोर्न शेल टोकनाइज़ेशन पर निर्भर करें. Java बाइनरी की रैपर स्क्रिप्ट में एक classPATH परिभाषा (सभी निर्भर जार ढूंढने के लिए) शामिल होती है और यह सही Java अनुवादक से संपर्क करती है. रैपर स्क्रिप्ट से जनरेट किए गए कमांड लाइन में मुख्य क्लास का नाम शामिल होता है. इसके बाद `"$@"` में क्लास के नाम के बाद, दूसरे आर्ग्युमेंट पास किए जा सकते हैं. हालांकि, जेवीएम से पार्स करने वाले आर्ग्युमेंट, कमांड लाइन पर क्लास के नाम से पहले दिए जाने चाहिए. क्लास का नाम सूची में शामिल होने से पहले, `jvm_flags` का कॉन्टेंट रैपर स्क्रिप्ट में जोड़ा जाता है. ध्यान रखें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं* होता है.
`launcher`	`Label; optional` ऐसी बाइनरी फ़ाइल तय करें जिसका इस्तेमाल JDK के साथ शामिल किए गए सामान्य `bin/java` प्रोग्राम के बजाय, आपके Java प्रोग्राम को चलाने के लिए किया जाएगा. टारगेट `cc_binary` होना चाहिए. कोई भी ऐसा `cc_binary` जो Java शुरू करने वाला एपीआई लागू करता है, उसे इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है. डिफ़ॉल्ट रूप से, बेज़ेल सामान्य 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` Java टारगेट को दी जाने वाली JAR फ़ाइलों की सूची, जो इस टारगेट पर निर्भर करती हैं.
`neverlink`	`Boolean; optional; default is False` इस लाइब्रेरी का इस्तेमाल, सिर्फ़ कंपाइलेशन के लिए करें और रनटाइम के दौरान नहीं. अगर लाइब्रेरी एक्ज़ीक्यूशन के दौरान रनटाइम एनवायरमेंट में उपलब्ध कराई जाएगी, तो यह उपयोगी है. इस तरह की लाइब्रेरी के उदाहरण, आईडीई प्लग-इन के लिए आईडीई एपीआई या स्टैंडर्ड जेडीके पर चलने वाले किसी भी कॉन्टेंट के लिए `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_लाइब्रेरी

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: स्रोत वाला संग्रह (&quat;source ja&kot;).

तर्क

एट्रिब्यूट
`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` तरह की सोर्स फ़ाइलें पैक नहीं की जाती और कंपाइल की जाती हैं. (इसका इस्तेमाल तब किया जा सकता है, जब आपको जनरेट करने के लिए बिना किसी नियम वाली `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई फ़ाइलों में से किसी भी फ़ाइल को जनरेट करता है, तो सोर्स फ़ाइल की तरह ही उनका इस्तेमाल किया जाएगा. इस आर्ग्युमेंट की हमेशा ज़रूरत होती है. हालांकि, `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर क्लास के बारे में बताता है या `runtime_deps` आर्ग्युमेंट के बारे में बताता है.
`data`	`List of labels; optional` रनटाइम के दौरान, इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. `data` के बारे में सामान्य टिप्पणियां देखें, जो सबसे ज़्यादा बनाए गए नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट पर मौजूद हैं. `java_library` बनने पर, बेज़ेल इन फ़ाइलों को कहीं भी नहीं रखते; अगर `data` फ़ाइलें जनरेट होती हैं, तो बेज़ेल उन्हें जनरेट करती हैं. कोई ऐसा टेस्ट बनाते समय जो `java_library` बैजल पर निर्भर करता है या `data` फ़ाइलों को रनफ़ाइल एरिया में लिंक करता है.
`resources`	`List of labels; optional` Java जार में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधन बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में मौजूद संसाधनों की जगह, प्रोजेक्ट के हिसाब से तय की जाती है. बेज़ेल पहले Maven' के स्टैंडर्ड डायरेक्ट्री लेआउट, (a &quat;src&kot; डायरेक्ट्री के बाद एक "resources&quat; डायरेक्ट्री ग्रैंड चाइल्ड) ढूंढते हैं. अगर उसे नहीं मिलता है, तो बेज़ेल फिर "java&quat; या &quat;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` पर लागू नहीं होता. खास जानकारी: अगर X कोड के बीच कोई डिपेंडेंसी पाथ है, तो X कोड को ऐक्सेस किया जा सकता है. इसकी शुरुआत `deps` साइज़ से होती है और इसके बाद शून्य या इससे ज़्यादा `exports` किनारों होते हैं. आइए, इसे समझने के लिए कुछ उदाहरण देखें. मान लें कि A, B पर निर्भर करता है और B C पर निर्भर करता है. इस मामले में C, A का ट्रांज़िशनल डिपेंडेंसी है. इसलिए, C' के सोर्स में बदलाव करने और A को फिर से बनाने से, हर चीज़ सही तरीके से बन जाएगी. हालांकि, A C में क्लास का इस्तेमाल नहीं कर पाएगा. इसकी अनुमति देने के लिए, या तो A को अपनी `deps` में C का एलान करना होगा या B की मदद से A (और A पर निर्भर कोई भी चीज़) को C (B's) `exports` एट्रिब्यूट में बदलकर आसान बना सकते हैं. एक्सपोर्ट की गई लाइब्रेरी को बंद करने की प्रोसेस, सीधे तौर पर लागू होने वाले सभी पैरंट नियमों के लिए उपलब्ध है. थोड़ा अलग उदाहरण लें: A, B पर निर्भर करता है, B, C और D पर निर्भर करता है और C को भी एक्सपोर्ट करता है, लेकिन D पर नहीं. अब A के पास C का ऐक्सेस है, लेकिन D का नहीं. अब, अगर C और D ने कुछ लाइब्रेरी एक्सपोर्ट की हैं, C' और D' तो, A सिर्फ़ C&#39 को ऐक्सेस कर सकता है; D&#39 को नहीं. अहम जानकारी: एक्सपोर्ट किया गया नियम नियमित तौर पर निर्भर नहीं करता. पिछले उदाहरण की तरह, अगर B, C को एक्सपोर्ट करता है और C का भी इस्तेमाल करना चाहता है, तो उसे भी अपनी सूची में `deps` को शामिल करना होगा.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए अतिरिक्त कंपाइलर विकल्प. &quat;वैरिएबल वैरिएबल&कोटेशन के विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद Javac को पास किए जाते हैं.
`neverlink`	`Boolean; optional; default is False` क्या इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए, रनटाइम के दौरान नहीं. अगर लाइब्रेरी एक्ज़ीक्यूशन के दौरान रनटाइम एनवायरमेंट में उपलब्ध कराई जाएगी, तो यह उपयोगी होता है. ऐसी लाइब्रेरी के उदाहरण IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चल रही सभी चीज़ों के लिए `tools.jar` हैं. ध्यान रखें कि `neverlink = 1`, कंपाइलर को इस लाइब्रेरी से मिले कॉन्टेंट को कंपाइल करके दिखाने वाले टारगेट को लागू करने से नहीं रोकता है, जैसा कि Java की लैंग्वेज स्पेसिफ़िकेशन में अनुमति दी गई है (जैसे, `String` या प्रिमिटिव टाइप की `static final` कॉन्स्टंट). इसलिए, इस्तेमाल करने का उदाहरण तब माना जाता है, जब रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से मेल खाती हो. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि वह सिर्फ़ उन जगहों पर अलग हो जहां जेएलएस, कंपाइल को इनलाइन करने की अनुमति नहीं देती है. साथ ही, यह जेएलएस के आने वाले वर्शन के लिए ज़रूरी है.
`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

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

Java_proto_लाइब्रेरी

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

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

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` तरह की सोर्स फ़ाइलें पैक नहीं की जाती और कंपाइल की जाती हैं. (इसका इस्तेमाल तब किया जा सकता है, जब आपको जनरेट करने के लिए बिना किसी नियम वाली `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई फ़ाइलों में से किसी भी फ़ाइल को जनरेट करता है, तो सोर्स फ़ाइल की तरह ही उनका इस्तेमाल किया जाएगा. इस आर्ग्युमेंट की हमेशा ज़रूरत होती है. हालांकि, `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर क्लास के बारे में बताता है या `runtime_deps` आर्ग्युमेंट के बारे में बताता है.
`resources`	`List of labels; optional` Java जार में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधन बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में मौजूद संसाधनों की जगह, प्रोजेक्ट के हिसाब से तय की जाती है. बेज़ेल पहले Maven' के स्टैंडर्ड डायरेक्ट्री लेआउट, (a &quat;src&kot; डायरेक्ट्री के बाद एक "resources&quat; डायरेक्ट्री ग्रैंड चाइल्ड) ढूंढते हैं. अगर उसे नहीं मिलता है, तो बेज़ेल फिर "java&quat; या &quat;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` बाइनरी फ़ाइल एक्ज़ीक्यूटेबल है या नहीं. एक्ज़ीक्यूटेबल बाइनरी, ट्रांज़िशन वाले Java Java की डिपेंडेंसी को डिप्लॉयमेंट जार में इकट्ठा करती हैं. हालांकि, उन्हें सीधे तौर पर लागू नहीं किया जा सकता. अगर इस एट्रिब्यूट को सेट किया जाता है, तो कोई रैपर स्क्रिप्ट नहीं बनाई जाती. अगर `launcher` या `main_class` एट्रिब्यूट सेट हैं, तो इसे 0 पर सेट करने में गड़बड़ी होती है.
`deploy_manifest_lines`	`List of strings; optional` `_deploy.jar` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ी जाने वाली लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट को नहीं* "वैरिएबल बनाएं</br>; की जगह लागू करें.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए अतिरिक्त कंपाइलर विकल्प. &quat;वैरिएबल वैरिएबल&कोटेशन के विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद Javac को पास किए जाते हैं.
`jvm_flags`	`List of strings; optional` इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में जोड़ने के लिए फ़्लैग की सूची. $(location) और &quat;वैरिएबल वैरिएबल</ot> के विकल्प के साथ-साथ, बोर्न शेल टोकनाइज़ेशन पर निर्भर करें. Java बाइनरी की रैपर स्क्रिप्ट में एक classPATH परिभाषा (सभी निर्भर जार ढूंढने के लिए) शामिल होती है और यह सही Java अनुवादक से संपर्क करती है. रैपर स्क्रिप्ट से जनरेट किए गए कमांड लाइन में मुख्य क्लास का नाम शामिल होता है. इसके बाद `"$@"` में क्लास के नाम के बाद, दूसरे आर्ग्युमेंट पास किए जा सकते हैं. हालांकि, जेवीएम से पार्स करने वाले आर्ग्युमेंट, कमांड लाइन पर क्लास के नाम से पहले दिए जाने चाहिए. क्लास का नाम सूची में शामिल होने से पहले, `jvm_flags` का कॉन्टेंट रैपर स्क्रिप्ट में जोड़ा जाता है. ध्यान रखें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं* होता है.
`launcher`	`Label; optional` ऐसी बाइनरी फ़ाइल तय करें जिसका इस्तेमाल JDK के साथ शामिल किए गए सामान्य `bin/java` प्रोग्राम के बजाय, आपके Java प्रोग्राम को चलाने के लिए किया जाएगा. टारगेट `cc_binary` होना चाहिए. कोई भी ऐसा `cc_binary` जो Java शुरू करने वाला एपीआई लागू करता है, उसे इस एट्रिब्यूट की वैल्यू के तौर पर बताया जा सकता है. डिफ़ॉल्ट रूप से, बेज़ेल सामान्य 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 क्लास का नाम बताता है. इसे सेट करना बहुत कम है. अगर यह तर्क हटाया जाता है, तो इसका पता लगाने के लिए, टारगेट और #39; `name` के साथ-साथ सोर्स-रूट-रिलेटिव पाथ का इस्तेमाल किया जाता है. अगर टेस्ट, रूट रूट के बाहर मौजूद है और `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_प्लग इन

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

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

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

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

तर्क

एट्रिब्यूट
`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` तरह की सोर्स फ़ाइलें पैक नहीं की जाती और कंपाइल की जाती हैं. (इसका इस्तेमाल तब किया जा सकता है, जब आपको जनरेट करने के लिए बिना किसी नियम वाली `.java` फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर नियम (आम तौर पर `genrule` या `filegroup`) ऊपर दी गई फ़ाइलों में से किसी भी फ़ाइल को जनरेट करता है, तो सोर्स फ़ाइल की तरह ही उनका इस्तेमाल किया जाएगा. इस आर्ग्युमेंट की हमेशा ज़रूरत होती है. हालांकि, `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर क्लास के बारे में बताता है या `runtime_deps` आर्ग्युमेंट के बारे में बताता है.
`data`	`List of labels; optional` रनटाइम के दौरान, इस लाइब्रेरी के लिए ज़रूरी फ़ाइलों की सूची. `data` के बारे में सामान्य टिप्पणियां देखें, जो सबसे ज़्यादा बनाए गए नियमों के हिसाब से तय किए गए सामान्य एट्रिब्यूट पर मौजूद हैं. `java_library` बनने पर, बेज़ेल इन फ़ाइलों को कहीं भी नहीं रखते; अगर `data` फ़ाइलें जनरेट होती हैं, तो बेज़ेल उन्हें जनरेट करती हैं. कोई ऐसा टेस्ट बनाते समय जो `java_library` बैजल पर निर्भर करता है या `data` फ़ाइलों को रनफ़ाइल एरिया में लिंक करता है.
`resources`	`List of labels; optional` Java जार में शामिल करने के लिए डेटा फ़ाइलों की सूची. अगर संसाधन बताए गए हैं, तो उन्हें कंपाइल करके बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में मौजूद संसाधनों की जगह, प्रोजेक्ट के हिसाब से तय की जाती है. बेज़ेल पहले Maven' के स्टैंडर्ड डायरेक्ट्री लेआउट, (a &quat;src&kot; डायरेक्ट्री के बाद एक "resources&quat; डायरेक्ट्री ग्रैंड चाइल्ड) ढूंढते हैं. अगर उसे नहीं मिलता है, तो बेज़ेल फिर "java&quat; या &quat;javatests" नाम की सबसे ऊपर वाली डायरेक्ट्री ढूंढती है; (उदाहरण के लिए, अगर संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस ह्यूरिस्टिक को बदला नहीं जा सकता. हालांकि, `resource_strip_prefix` फ़ाइल का इस्तेमाल, रिसॉर्स फ़ाइलों के लिए किसी खास वैकल्पिक डायरेक्ट्री के बारे में बताने के लिए किया जा सकता है. संसाधन, स्रोत फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं.
`generates_api`	`Boolean; optional; default is False` यह एट्रिब्यूट, एपीआई प्रोसेस करने वाले एनोटेशन प्रोसेसर की पहचान करता है. अगर कोई नियम एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो दूसरे नियम इस आधार पर जनरेट किए गए कोड का इस्तेमाल कर सकते हैं. ऐसा तभी होगा, जब उन कोड को इकट्ठा करने के नियम, जनरेट करने के नियम के बाद शेड्यूल किए गए हों. यह एट्रिब्यूट, बेजल को निर्देश देता है कि जब --java_header_compilation चालू किया गया हो, तो उसे शेड्यूल करने की शर्तें लागू की जाएं. चेतावनी: बिल्ड की परफ़ॉर्मेंस पर इसका असर पड़ता है. इसका इस्तेमाल सिर्फ़ ज़रूरी होने पर ही करें.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए अतिरिक्त कंपाइलर विकल्प. &quat;वैरिएबल वैरिएबल&कोटेशन के विकल्प और बोर्न शेल टोकनाइज़ेशन पर निर्भर करता है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद Javac को पास किए जाते हैं.
`neverlink`	`Boolean; optional; default is False` क्या इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए, रनटाइम के दौरान नहीं. अगर लाइब्रेरी एक्ज़ीक्यूशन के दौरान रनटाइम एनवायरमेंट में उपलब्ध कराई जाएगी, तो यह उपयोगी होता है. ऐसी लाइब्रेरी के उदाहरण IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चल रही सभी चीज़ों के लिए `tools.jar` हैं. ध्यान रखें कि `neverlink = 1`, कंपाइलर को इस लाइब्रेरी से मिले कॉन्टेंट को कंपाइल करके दिखाने वाले टारगेट को लागू करने से नहीं रोकता है, जैसा कि Java की लैंग्वेज स्पेसिफ़िकेशन में अनुमति दी गई है (जैसे, `String` या प्रिमिटिव टाइप की `static final` कॉन्स्टंट). इसलिए, इस्तेमाल करने का उदाहरण तब माना जाता है, जब रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से मेल खाती हो. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि वह सिर्फ़ उन जगहों पर अलग हो जहां जेएलएस, कंपाइल को इनलाइन करने की अनुमति नहीं देती है. साथ ही, यह जेएलएस के आने वाले वर्शन के लिए ज़रूरी है.
`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_रनटाइम

java_runtime(name, srcs, compatible_with, deprecation, distribs, features, hermetic_srcs, java, java_home, lib_modules, licenses, restricted_to, tags, target_compatible_with, testonly, 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` रनटाइम में सभी फ़ाइलें.
`hermetic_srcs`	`List of labels; optional` रनटाइम में फ़ाइलें, हर्मेटिक डिप्लॉयमेंट के लिए ज़रूरी हैं.
`java`	`Label; optional` एक्ज़ीक्यूटेबल एक्ज़ीक्यूटेबल का पाथ.
`java_home`	`String; optional` रनटाइम के रूट का पाथ. "Make&कोटेशन वैरिएबल के तहत. अगर यह पाथ ऐब्सलूट है, तो नियम से एक ऐसे पाथ के बारे में पता चलता है जो हर्मिटिक कोड का इस्तेमाल नहीं करता. ऐसे में, `srcs` और `java` एट्रिब्यूट खाली होने चाहिए.
`lib_modules`	`Label; optional` हर्मेटिक डिप्लॉयमेंट के लिए लिब/मॉड्यूल फ़ाइल ज़रूरी है.

जैव_टूलचेन

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's -bootclasspath फ़्लैग से मेल खाता है.
`deps_checker`	`List of labels; optional` ImportDepsChecker डिप्लॉयमेंट जार का लेबल.
`forcibly_disable_header_compilation`	`Boolean; optional; default is False` ऐसे प्लैटफ़ॉर्म पर हेडर कंपाइलेशन की सुविधा बंद करने के लिए --java_header_compilation को बदलता है जो इसके साथ काम नहीं करते हैं, उदाहरण के लिए, JDK 7 Bazen.
`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` ija एक्ज़ीक्यूटेबल का लेबल.
`jacocorunner`	`Label; optional` JacocoकवरageRunner डिप्लॉयमेंट जार का लेबल.
`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 का इस्तेमाल करते समय, JVM के लिए आर्ग्युमेंट की सूची.
`javac_supports_multiplex_workers`	`Boolean; optional; default is True` अगर JavaBuilder को मल्टीप्लेक्स स्थायी वर्कर के तौर पर चलाने की सुविधा मिलती है, तो सही नहीं होता है.
`javac_supports_workers`	`Boolean; optional; default is True` अगर JavaBuilder लगातार काम करने वाले व्यक्ति के रूप में चल रहा है, तो सही नहीं है.
`javacopts`	`List of strings; optional` Java कंपाइलर के लिए अतिरिक्त तर्कों की सूची. संभावित Java कंपाइलर फ़्लैग की पूरी सूची के लिए, कृपया Java कंपाइलर दस्तावेज़ देखें.
`jvm_opts`	`List of strings; optional` Java कंपाइलर शुरू करते समय, JVM के लिए तर्कों की सूची. इस विकल्प के लिए, संभावित फ़्लैग की बड़ी सूची देखने के लिए, कृपया 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 दस्तावेज़ देखें.