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

Java नियम

नियम

java_binary
java_import
java_library
java_lite_proto_library
java_proto_library
java_test
java_package_configuration
java_plugin
java_runtime
java_toolchain

java_binary

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

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

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

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

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

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

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

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

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

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

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

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

तर्क

एट्रिब्यूट
`name`	`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` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर से तय होती है. Bazel पहले, Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद "रिसॉर्स" डायरेक्ट्री का पोलैंड) खोजता है. अगर यह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर की डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, रिसॉर्स फ़ाइलों के लिए कोई खास डायरेक्ट्री बताने के लिए, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं.
`classpath_resources`	`List of labels; optional` इस विकल्प का इस्तेमाल तब न करें, जब आपके पास कोई और तरीका न हो) रिसॉर्स की सूची, जो JavaScript ट्री के रूट में होनी चाहिए. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तीसरे पक्ष की लाइब्रेरी के साथ किया जा सकता है. इसके लिए, यह ज़रूरी है कि उनके रिसॉर्स, क्लासपाथ पर `"myconfig.xml"` के तौर पर मौजूद हों. ऐसा सिर्फ़ बाइनरी पर किया जा सकता है, लाइब्रेरी पर नहीं. ऐसा, नेमस्पेस के विवादों के खतरे की वजह से होता है.
`create_executable`	`Boolean; optional; nonconfigurable; default is True` क्या बाइनरी फ़ाइल को एक्ज़ीक्यूट किया जा सकता है. नहीं किए जा सकने वाले बाइनरी, डिप्लॉय किए गए जार में ट्रांज़िट रनटाइम 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` फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट की जगह पर "वैरिएबल बनाएं" लागू नहीं* है.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं.
`jvm_flags`	`List of strings; optional` इस बाइनरी को चलाने के लिए, रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. यह विकल्प $(location) और "Make वैरिएबल" के बदले लागू होता है. साथ ही, बर्न शेल टोकनाइज़ेशन पर निर्भर करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, `"$@"` होता है, ताकि क्लास के नाम के बाद, अन्य आर्ग्युमेंट को पास किया जा सके. हालांकि, जेवीएम से पार्स करने के लिए बने तर्कों को, कमांड लाइन पर क्लासनाम से पहले बताया जाना चाहिए. क्लास का नाम शामिल करने से पहले, `jvm_flags` के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं पड़ता*.
`launcher`	`Label; optional` कोई बाइनरी बताएं, जिसका इस्तेमाल आपके Java प्रोग्राम को चलाने के लिए किया जाएगा, न कि JDK के साथ शामिल सामान्य `bin/java` प्रोग्राम के लिए. टारगेट `cc_binary` होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, Java Invocation API को लागू करने वाले किसी भी `cc_binary` को वैल्यू के तौर पर दिखाया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. मिलते-जुलते `--java_launcher` बैजल फ़्लैग से, सिर्फ़ उन `java_binary` और `java_test` टारगेट पर असर पड़ता है जिनके लिए `launcher` एट्रिब्यूट नहीं बताया गया है. ध्यान दें कि आपके नेटिव (C++, SWIG, JNI) डिपेंडेंसी इस आधार पर अलग-अलग तरीके से बनाई जाएंगी कि JDK लॉन्चर का इस्तेमाल किया जा रहा है या किसी दूसरे लॉन्चर का: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी `{name}_nativedeps.so` नाम की शेयर की गई लाइब्रेरी के तौर पर बनाई जाती हैं. इसमें `{name}`, इस java_binary नियम का `name` एट्रिब्यूट है. इस कॉन्फ़िगरेशन में, लिंकर ने इस्तेमाल नहीं किया गया कोड नहीं हटाया है. अगर किसी दूसरे लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी, `{name}_nativedeps` नाम की बाइनरी से स्टैटिक रूप से लिंक की जाती हैं. इसमें `{name}` इस java_binary नियम का `name` एट्रिब्यूट है. इस मामले में, लिंक करने वाला टैग, नतीजे में दिखने वाली बाइनरी में मौजूद ऐसे किसी भी कोड को हटा देगा जिसे उसके इस्तेमाल नहीं किया गया है. इसका मतलब है कि जेएनआई से ऐक्सेस किया गया कोई भी C++ कोड तब तक लिंक नहीं किया जा सकता, जब तक उस `cc_library` टारगेट में `alwayslink = 1` की जानकारी न दी गई हो. डिफ़ॉल्ट JDK लॉन्चर के अलावा किसी दूसरे लॉन्चर का इस्तेमाल करने पर, `*_deploy.jar` के आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
`main_class`	`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 या transaction_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` टेस्ट रनर (डिफ़ॉल्ट रूप से `com.google.testing.junit.runner.BazelTestRunner`) क्लास को Java प्रोग्राम के मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करें. साथ ही, टेस्ट रनर को, `bazel.test_suite` सिस्टम प्रॉपर्टी की वैल्यू के तौर पर टेस्ट क्लास दें. इसका इस्तेमाल डिफ़ॉल्ट व्यवहार को बदलने के लिए किया जा सकता है. इसमें `java_test` नियमों के लिए टेस्ट रनर का इस्तेमाल किया जाता है, न कि `java_binary` नियमों के लिए. इसकी संभावना कम है कि आप ऐसा करना चाहेंगे. इसका एक इस्तेमाल `AllTest` नियमों के लिए होता है, जिन्हें किसी दूसरे नियम (उदाहरण के लिए, टेस्ट करने से पहले डेटाबेस सेट अप करने के लिए) से शुरू किया जाता है. `AllTest` नियम को `java_binary` के तौर पर बताया जाना चाहिए. हालांकि, इसके बाद भी टेस्ट रनर को मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करना चाहिए. टेस्ट रनर क्लास के नाम को `main_class` एट्रिब्यूट से बदला जा सकता है.

java_import

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

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

उदाहरण

    java_import(
        name = "maven_model",
        jars = [
            "maven_model/maven-aether-provider-3.2.3.jar",
            "maven_model/maven-model-3.2.3.jar",
            "maven_model/maven-model-builder-3.2.3.jar",
        ],
    )

तर्क

एट्रिब्यूट
`name`	`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` रनटाइम के दौरान नहीं, बल्कि कंपाइलेशन के लिए इस लाइब्रेरी का इस्तेमाल करें. यह तब काम आता है, जब लाइब्रेरी को एक्ज़ीक्यूट करने के दौरान, रनटाइम एनवायरमेंट से उपलब्ध कराया जाएगा. इस तरह की लाइब्रेरी के उदाहरण, IDE प्लग-इन के लिए IDE API या स्टैंडर्ड 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: ऐसा संग्रह जिसमें सोर्स होते हैं ("सोर्स जार").

तर्क

एट्रिब्यूट
`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` बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं रखता है. अगर `data` फ़ाइलें जनरेट की जाती हैं, तो Bazel उन्हें जनरेट करता है. इस `java_library` Bazel पर निर्भर टेस्ट बनाते समय, `data` फ़ाइलों को रनफ़ाइल एरिया में कॉपी या लिंक किया जाता है.
`resources`	`List of labels; optional` Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें कंपाइलेशन से बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर से तय होती है. Bazel पहले, Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद "रिसॉर्स" डायरेक्ट्री का पोलैंड) खोजता है. अगर यह नहीं मिलता है, तो Bazel "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` के लिए सही नहीं है. खास जानकारी: X नियम को Y में ऐक्सेस कर सकता है. ऐसा तब होता है, जब उनके बीच ऐसा डिपेंडेंसी पाथ मौजूद हो जो `deps` किनारे से शुरू होता है और उसके बाद `exports` किनारे होता है. यह समझने के लिए हम कुछ उदाहरण देखते हैं. मान लें कि A, B पर निर्भर है और B, C पर निर्भर है. इस मामले में, C, A की ट्रांज़िशनिव डिपेंडेंसी है. इसलिए, C के सोर्स बदलने और A को फिर से बनाने पर, हर चीज़ सही तरीके से फिर से बन जाएगी. हालांकि, A, C में क्लास इस्तेमाल नहीं कर पाएगा. इसकी अनुमति देने के लिए, A को अपने `deps` में C का एलान करना होगा या B, C (B के) `exports` एट्रिब्यूट में C का एलान करके, A (और A पर निर्भर होने वाली किसी भी चीज़) के लिए इसे आसान बना सकता है. एक्सपोर्ट की गई लाइब्रेरी को बंद करने की सुविधा, सीधे तौर पर दिए गए सभी पैरंट नियमों पर लागू होती है. थोड़ा अलग उदाहरण लें: A, B पर निर्भर है, B, C और D पर निर्भर है, और यह C और D पर निर्भर करता है. अब A के पास, C का ऐक्सेस है, लेकिन D का नहीं. अब, अगर C और D ने कुछ लाइब्रेरी, C' और D' एक्सपोर्ट की हैं, तो A सिर्फ़ C' को ऐक्सेस कर सकता है, D' को नहीं. अहम जानकारी: एक्सपोर्ट किया गया नियम, सामान्य डिपेंडेंसी नहीं होती है. ऊपर दिए गए उदाहरण की तरह ही, अगर B, C को एक्सपोर्ट करता है और C का भी इस्तेमाल करना चाहता है, तो उसे भी उसे अपने `deps` में शामिल करना होगा.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं.
`neverlink`	`Boolean; optional; default is False` इस लाइब्रेरी का इस्तेमाल, सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए, रनटाइम के दौरान नहीं. यह तब काम आता है, जब स्क्रिप्ट चलाने के दौरान रनटाइम एनवायरमेंट से लाइब्रेरी उपलब्ध कराई जाएगी. आईडीई प्लग-इन के लिए 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 या transaction_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` प्रकार की स्रोत फ़ाइलें अनपैक और कंपाइल की जाती हैं. (यह तब फ़ायदेमंद होता है, जब आपको `.java` फ़ाइलों का एक सेट जनरेट करने के लिए जनरेट किए जाने वाले नियम की ज़रूरत हो.) नियम: अगर नियम (आम तौर पर, `genrule` या `filegroup`) ऊपर दी गई कोई भी फ़ाइल जनरेट करता है, तो उसका इस्तेमाल सोर्स फ़ाइलों के लिए बताए गए तरीके से ही किया जाएगा. आम तौर पर, इस तर्क की ज़रूरत होती है. हालांकि, अगर `main_class` एट्रिब्यूट, रनटाइम क्लासपाथ पर किसी क्लास के बारे में बताता है या आपने `runtime_deps` तर्क दिया है, तो ऐसा नहीं होगा.
`resources`	`List of labels; optional` Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें कंपाइलेशन से बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर से तय होती है. Bazel पहले, Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद "रिसॉर्स" डायरेक्ट्री का पोलैंड) खोजता है. अगर यह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर की डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन `<workspace root>/x/java/y/java/z` पर है, तो संसाधन का पाथ `y/java/z` होगा. इस अनुमान को बदला नहीं जा सकता. हालांकि, रिसॉर्स फ़ाइलों के लिए कोई खास डायरेक्ट्री बताने के लिए, `resource_strip_prefix` एट्रिब्यूट का इस्तेमाल किया जा सकता है. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकते हैं.
`classpath_resources`	`List of labels; optional` इस विकल्प का इस्तेमाल तब न करें, जब आपके पास कोई और तरीका न हो) रिसॉर्स की सूची, जो JavaScript ट्री के रूट में होनी चाहिए. इस एट्रिब्यूट का इस्तेमाल सिर्फ़ तीसरे पक्ष की लाइब्रेरी के साथ किया जा सकता है. इसके लिए, यह ज़रूरी है कि उनके रिसॉर्स, क्लासपाथ पर `"myconfig.xml"` के तौर पर मौजूद हों. ऐसा सिर्फ़ बाइनरी पर किया जा सकता है, लाइब्रेरी पर नहीं. ऐसा, नेमस्पेस के विवादों के खतरे की वजह से होता है.
`create_executable`	`Boolean; optional; nonconfigurable; default is True` क्या बाइनरी फ़ाइल को एक्ज़ीक्यूट किया जा सकता है. नहीं किए जा सकने वाले बाइनरी, डिप्लॉय किए गए जार में ट्रांज़िट रनटाइम Java डिपेंडेंसी इकट्ठा करते हैं. हालांकि, इन्हें सीधे तौर पर एक्ज़ीक्यूट नहीं किया जा सकता. अगर यह एट्रिब्यूट सेट है, तो कोई रैपर स्क्रिप्ट नहीं बनाई जाएगी. अगर `launcher` या `main_class` एट्रिब्यूट को सेट किया गया है, तो इसे 0 पर सेट करना गड़बड़ी है.
`deploy_manifest_lines`	`List of strings; optional` `_deploy.jar` टारगेट के लिए जनरेट की गई `META-INF/manifest.mf` फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट की जगह पर "वैरिएबल बनाएं" लागू नहीं* है.
`javacopts`	`List of strings; optional` इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं.
`jvm_flags`	`List of strings; optional` इस बाइनरी को चलाने के लिए, रैपर स्क्रिप्ट में एम्बेड किए जाने वाले फ़्लैग की सूची. यह विकल्प $(location) और "Make वैरिएबल" के बदले लागू होता है. साथ ही, बर्न शेल टोकनाइज़ेशन पर निर्भर करता है. Java बाइनरी के लिए रैपर स्क्रिप्ट में एक CLASSPATH परिभाषा शामिल है (सभी डिपेंडेंट जार को ढूंढने के लिए) और सही Java इंटरप्रेटर को शुरू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम होता है. इसके बाद, `"$@"` होता है, ताकि क्लास के नाम के बाद, अन्य आर्ग्युमेंट को पास किया जा सके. हालांकि, जेवीएम से पार्स करने के लिए बने तर्कों को, कमांड लाइन पर क्लासनाम से पहले बताया जाना चाहिए. क्लास का नाम शामिल करने से पहले, `jvm_flags` के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट का `_deploy.jar` आउटपुट पर कोई असर नहीं पड़ता*.
`launcher`	`Label; optional` कोई बाइनरी बताएं, जिसका इस्तेमाल आपके Java प्रोग्राम को चलाने के लिए किया जाएगा, न कि JDK के साथ शामिल सामान्य `bin/java` प्रोग्राम के लिए. टारगेट `cc_binary` होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, Java Invocation API को लागू करने वाले किसी भी `cc_binary` को वैल्यू के तौर पर दिखाया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. मिलते-जुलते `--java_launcher` बैजल फ़्लैग से, सिर्फ़ उन `java_binary` और `java_test` टारगेट पर असर पड़ता है जिनके लिए `launcher` एट्रिब्यूट नहीं बताया गया है. ध्यान दें कि आपके नेटिव (C++, SWIG, JNI) डिपेंडेंसी इस आधार पर अलग-अलग तरीके से बनाई जाएंगी कि JDK लॉन्चर का इस्तेमाल किया जा रहा है या किसी दूसरे लॉन्चर का: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी `{name}_nativedeps.so` नाम की शेयर की गई लाइब्रेरी के तौर पर बनाई जाती हैं. इसमें `{name}`, इस java_binary नियम का `name` एट्रिब्यूट है. इस कॉन्फ़िगरेशन में, लिंकर ने इस्तेमाल नहीं किया गया कोड नहीं हटाया है. अगर किसी दूसरे लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी, `{name}_nativedeps` नाम की बाइनरी से स्टैटिक रूप से लिंक की जाती हैं. इसमें `{name}` इस java_binary नियम का `name` एट्रिब्यूट है. इस मामले में, लिंक करने वाला टैग, नतीजे में दिखने वाली बाइनरी में मौजूद ऐसे किसी भी कोड को हटा देगा जिसे उसके इस्तेमाल नहीं किया गया है. इसका मतलब है कि जेएनआई से ऐक्सेस किया गया कोई भी C++ कोड तब तक लिंक नहीं किया जा सकता, जब तक उस `cc_library` टारगेट में `alwayslink = 1` की जानकारी न दी गई हो. डिफ़ॉल्ट JDK लॉन्चर के अलावा किसी दूसरे लॉन्चर का इस्तेमाल करने पर, `*_deploy.jar` के आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
`main_class`	`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 या transaction_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` और उसके सोर्स-रूट-रिलेटिव पाथ का इस्तेमाल करके, इसका अनुमान लगाया जाएगा. अगर टेस्ट किसी ऐसे सोर्स रूट के बाहर मौजूद है, जिसकी जानकारी पहले से मौजूद है, तो `test_class` के सेट न होने पर Bazel गड़बड़ी की शिकायत करेगा. JUnit3 के लिए, टेस्ट क्लास या तो `junit.framework.TestCase` की सब-क्लास होनी चाहिए या फिर इसमें सार्वजनिक स्टैटिक `suite()` तरीका होना चाहिए, जो `junit.framework.Test` (या `Test` की सब-क्लास) दिखाए. JUnit4 के लिए, क्लास की व्याख्या `org.junit.runner.RunWith` की मदद से की जानी चाहिए. यह एट्रिब्यूट, `java_test` के कई नियमों को एक ही `Test` (`TestCase`, `TestSuite`, ...) शेयर करने की अनुमति देता है. आम तौर पर, इसे `jvm_flags=['-Dkey=value']` के ज़रिए ज़्यादा जानकारी भेजी जाती है. ऐसा इसलिए किया जाता है, ताकि हर मामले में इसका व्यवहार अलग-अलग हो, जैसे कि टेस्ट का अलग सबसेट चलाना. यह एट्रिब्यूट, `javatests` ट्री के बाहर Java टेस्ट को इस्तेमाल करने की सुविधा भी चालू करता है.
`use_launcher`	`Boolean; optional; default is True` बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए या नहीं. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो लॉन्चर एट्रिब्यूट और इससे जुड़े `--java_launcher` फ़्लैग को इस टारगेट के लिए अनदेखा किया जाएगा.
`use_testrunner`	`Boolean; optional; default is True` टेस्ट रनर (डिफ़ॉल्ट रूप से `com.google.testing.junit.runner.BazelTestRunner`) क्लास को Java प्रोग्राम के मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करें. साथ ही, टेस्ट रनर को, `bazel.test_suite` सिस्टम प्रॉपर्टी की वैल्यू के तौर पर टेस्ट क्लास दें. इसका इस्तेमाल डिफ़ॉल्ट व्यवहार को बदलने के लिए किया जा सकता है. इसमें `java_test` नियमों के लिए टेस्ट रनर का इस्तेमाल किया जाता है, न कि `java_binary` नियमों के लिए. इसकी संभावना कम है कि आप ऐसा करना चाहेंगे. इसका एक इस्तेमाल `AllTest` नियमों के लिए होता है, जिन्हें किसी दूसरे नियम (उदाहरण के लिए, टेस्ट करने से पहले डेटाबेस सेट अप करने के लिए) से शुरू किया जाता है. `AllTest` नियम को `java_binary` के तौर पर बताया जाना चाहिए. हालांकि, इसके बाद भी टेस्ट रनर को मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करना चाहिए. टेस्ट रनर क्लास के नाम को `main_class` एट्रिब्यूट से बदला जा सकता है.

java_package_configuration

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

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

उदाहरण:

java_package_configuration(
    name = "my_configuration",
    packages = [":my_packages"],
    javacopts = ["-Werror"],
)

package_group(
    name = "my_packages",
    packages = [
        "//com/my/project/...",
        "-//com/my/project/testing/...",
    ],
)

java_toolchain(
    ...,
    package_configuration = [
        ":my_configuration",
    ]
)

तर्क

एट्रिब्यूट
`name`	`Name; required` इस टारगेट के लिए एक खास नाम.
`data`	`List of labels; optional` रनटाइम के दौरान, इस कॉन्फ़िगरेशन के लिए ज़रूरी फ़ाइलों की सूची.
`javacopts`	`List of strings; optional` Java कंपाइलर फ़्लैग.
`packages`	`List of labels; optional` `package_group` के वे सेट जिन पर कॉन्फ़िगरेशन लागू किया जाना चाहिए.

java_plugin

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

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

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

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

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

तर्क

एट्रिब्यूट
`name`	`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` बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं रखता है. अगर `data` फ़ाइलें जनरेट की जाती हैं, तो Bazel उन्हें जनरेट करता है. इस `java_library` Bazel पर निर्भर टेस्ट बनाते समय, `data` फ़ाइलों को रनफ़ाइल एरिया में कॉपी या लिंक किया जाता है.
`resources`	`List of labels; optional` Java जार में शामिल की जाने वाली डेटा फ़ाइलों की सूची. अगर रिसॉर्स के बारे में बताया गया है, तो उन्हें कंपाइलेशन से बनाई गई सामान्य `.class` फ़ाइलों के साथ जार में बंडल किया जाएगा. जार फ़ाइल में रिसॉर्स की जगह, प्रोजेक्ट के स्ट्रक्चर से तय होती है. Bazel पहले, Maven के स्टैंडर्ड डायरेक्ट्री लेआउट (एक "src" डायरेक्ट्री के बाद "रिसॉर्स" डायरेक्ट्री का पोलैंड) खोजता है. अगर यह नहीं मिलता है, तो Bazel "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` इस लाइब्रेरी के लिए कंपाइलर के ज़्यादा विकल्प. यह नीति, "बनाएं वैरिएबल" के विकल्प और बॉर्न शेल टोकनाइज़ेशन पर निर्भर करती है. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर के विकल्पों के बाद, javac को पास किए जाते हैं.
`neverlink`	`Boolean; optional; default is False` इस लाइब्रेरी का इस्तेमाल, सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए, रनटाइम के दौरान नहीं. यह तब काम आता है, जब स्क्रिप्ट चलाने के दौरान रनटाइम एनवायरमेंट से लाइब्रेरी उपलब्ध कराई जाएगी. आईडीई प्लग-इन के लिए 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 या transaction_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, 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` यह JavaScript एक्ज़ीक्यूटेबल का पाथ है.
`java_home`	`String; optional` रनटाइम के रूट का पाथ. "बनाएं" वैरिएबल के विकल्प पर निर्भर करता है. अगर यह पाथ पूरा है, तो यह नियम एक लोकप्रिय पाथ वाले नॉन-हर्मेटिक Java रनटाइम को दिखाता है. ऐसे में, `srcs` और `java` एट्रिब्यूट की वैल्यू डालना ज़रूरी है.
`lib_modules`	`Label; optional` हर्मेटिक डिप्लॉयमेंट के लिए ज़रूरी lib/modules फ़ाइल.

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 लिंट को शुरू करते समय, JVM के लिए तर्कों की सूची.
`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` PriceDepsChecker का लेबल, जार को डिप्लॉय करता है.
`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` Iजार की एक्ज़ीक्यूटेबल फ़ाइल का लेबल.
`jacocorunner`	`Label; optional` JacococoCoverageRunner का लेबल जार डिप्लॉय किया गया.
`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` SingleJar डिप्लॉय जार का लेबल.
`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` terbine_jvm_opts में लेबल-बढ़ाने के लिए उपलब्ध डेटा के लेबल.
`turbine_jvm_opts`	`List of strings; optional` टर्बाइन को शुरू करते समय, JVM के लिए तर्कों की सूची.
`xlint`	`List of strings; optional` डिफ़ॉल्ट सूची में जोड़ने या उससे हटाने के लिए चेतावनी की सूची. इसके पहले डैश लगाकर इसे हटा दिया जाता है. ज़्यादा जानकारी के लिए, -Xlint विकल्पों पर Javac दस्तावेज़ देखें.