Java के नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

नियम

• java_binary
• java_import
• java_library
• java_test
• java_package_configuration
• java_plugin
• java_runtime
• java_single_jar
• java_toolchain

java_binary

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

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

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

रैपर स्क्रिप्ट में कई यूनीक फ़्लैग इस्तेमाल किए जा सकते हैं. रैपर के ज़रिए कॉन्फ़िगर किए जा सकने वाले फ़्लैग और एनवायरमेंट वैरिएबल की सूची देखने के लिए, java_stub_template.txt पर जाएं.

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

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

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

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

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

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

सोर्स फ़ाइल के नाम का इस्तेमाल करना अच्छा होता है. यह ऐप्लिकेशन का मुख्य एंट्री पॉइंट होता है. इसमें एक्सटेंशन नहीं होता. उदाहरण के लिए, अगर आपके एंट्री पॉइंट का नाम Main.java है, तो आपका नाम Main हो सकता है.

java_binary नियम में deps एट्रिब्यूट का इस्तेमाल, srcs के बिना नहीं किया जा सकता. ऐसे नियम के लिए, 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	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. deps के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. इस एट्रिब्यूट की वैल्यू सबमिट करना ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, कुछ मामलों में ऐसा नहीं होता. इन अपवादों के बारे में यहां बताया गया है. .java टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई .java फ़ाइलों के लिए, आम तौर पर फ़ाइल के नाम के बजाय, जनरेट करने वाले नियम का नाम यहां डालने का सुझाव दिया जाता है. इससे न सिर्फ़ नियम को पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को ज़्यादा बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम का outs. आपको deps में जनरेट करने वाला नियम नहीं डालना चाहिए, क्योंकि यह कोई काम का नहीं है. .srcjar टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से .java फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर कोई नियम (आम तौर पर genrule या filegroup) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए किया जाता है. यह आर्ग्युमेंट ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, अगर main_class एट्रिब्यूट, रनटाइम क्लासपाथ पर किसी क्लास की जानकारी देता है या आपने runtime_deps आर्ग्युमेंट दिया है, तो यह ज़रूरी नहीं है.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. data के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं.
resources	लेबल की सूची; डिफ़ॉल्ट [] है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट हुई सामान्य .class फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह लेआउट, "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री के पोते की तरह होता है. अगर वह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन <workspace root>/x/java/y/java/z पर है, तो संसाधन का पाथ y/java/z होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, resource_strip_prefix एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरी डायरेक्ट्री तय की जा सकती है.
add_exports	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी को दिए गए module या package को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग से जुड़ा है.
add_opens	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी को, दिए गए module या package को रिफ़्लेक्टिव तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग से जुड़ा है.
bootclasspath	लेबल; डिफ़ॉल्ट रूप से None प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
classpath_resources	लेबल की सूची; डिफ़ॉल्ट [] है इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई दूसरा विकल्प न हो) उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का एक ही मकसद है, तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना जिनके लिए ज़रूरी है कि उनके रिसॉर्स, क्लासपाथ पर "myconfig.xml" के तौर पर मिलें. नेमस्पेस के टकराव की आशंका की वजह से, इसे सिर्फ़ बाइनरी पर इस्तेमाल करने की अनुमति है, न कि लाइब्रेरी पर.
create_executable	बूलियन; डिफ़ॉल्ट तौर पर True इस्तेमाल नहीं किया जा सकता. इसके बजाय, java_single_jar का इस्तेमाल करें.
deploy_env	लेबल की सूची; डिफ़ॉल्ट [] है इस बाइनरी के डिप्लॉयमेंट एनवायरमेंट को दिखाने वाले अन्य java_binary टारगेट की सूची. इस एट्रिब्यूट की वैल्यू तब सेट करें, जब कोई ऐसा प्लग इन बनाया जा रहा हो जिसे किसी दूसरे java_binary से लोड किया जाएगा. इस एट्रिब्यूट को सेट करने पर, इस बाइनरी के रनटाइम क्लासपाथ (और डिप्लॉय किए गए jar) से उन सभी डिपेंडेंसी को हटा दिया जाता है जो इस बाइनरी और deploy_env में बताए गए टारगेट के बीच शेयर की जाती हैं.
deploy_manifest_lines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] *_deploy.jar टारगेट के लिए जनरेट की गई META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट में, "वैरिएबल बनाएं" विकल्प का इस्तेमाल करके बदलाव नहीं किया जा सकता.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस बाइनरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
jvm_flags	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में जोड़ने के लिए फ़्लैग की सूची. $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से. Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH परिभाषा शामिल होती है, ताकि सभी डिपेंडेंट (आश्रित) jar ढूंढे जा सकें. साथ ही, यह सही Java इंटरप्रेटर को भी चालू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम और उसके बाद "$@" होता है, ताकि क्लास के नाम के बाद अन्य आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM के पास पार्स करने के लिए जिन आर्ग्युमेंट का इस्तेमाल करना है उन्हें कमांड लाइन पर क्लास के नाम से पहले तय करना होगा. क्लास का नाम सूची में शामिल होने से पहले, jvm_flags के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट का *_deploy.jar आउटपुट पर कोई असर नहीं पड़ता.
launcher	लेबल; डिफ़ॉल्ट रूप से None JDK में शामिल सामान्य bin/java प्रोग्राम के बजाय, अपने Java प्रोग्राम को चलाने के लिए इस्तेमाल किए जाने वाले बाइनरी को तय करें. टारगेट एक cc_binary होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, Java Invocation API को लागू करने वाला कोई भी cc_binary दिया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. इससे जुड़े --java_launcher Bazel फ़्लैग का असर सिर्फ़ उन java_binary और java_test टारगेट पर पड़ता है जिनके लिए launcher एट्रिब्यूट की वैल्यू न दी गई है. ध्यान दें कि JDK लॉन्चर या किसी अन्य लॉन्चर का इस्तेमाल करने पर, आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी अलग-अलग तरीके से बनाई जाएंगी: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी को {name}_nativedeps.so नाम की शेयर की गई लाइब्रेरी के तौर पर बनाया जाता है. यहां {name}, इस java_binary नियम का name एट्रिब्यूट है. इस कॉन्फ़िगरेशन में, लिंकर इस्तेमाल न किए गए कोड को नहीं हटाता. अगर किसी दूसरे लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी को {name}_nativedeps नाम के बाइनरी में स्टैटिक तौर पर लिंक किया जाता है. यहां {name}, इस java_binary नियम का name एट्रिब्यूट है. इस मामले में, लिंकर उस कोड को हटा देगा जो उसके हिसाब से, बाइनरी में इस्तेमाल नहीं किया गया है. इसका मतलब है कि सिर्फ़ JNI के ज़रिए ऐक्सेस किया गया कोई भी C++ कोड तब तक लिंक नहीं किया जा सकता, जब तक कि cc_library टारगेट में alwayslink = True की जानकारी न दी गई हो. डिफ़ॉल्ट JDK लॉन्चर के अलावा किसी दूसरे लॉन्चर का इस्तेमाल करने पर, *_deploy.jar आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
main_class	स्ट्रिंग; डिफ़ॉल्ट रूप से "" एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, main() तरीके वाली क्लास का नाम. अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो उसे srcs=[...] सूची की ज़रूरत नहीं होती. इस एट्रिब्यूट की मदद से, किसी ऐसी Java लाइब्रेरी से एक ऐसी एक्सीक्यूटेबल बनाई जा सकती है जिसमें पहले से ही एक या उससे ज़्यादा main() तरीके मौजूद हों. इस एट्रिब्यूट की वैल्यू, सोर्स फ़ाइल नहीं, बल्कि क्लास का नाम होती है. क्लास, रनटाइम के दौरान उपलब्ध होनी चाहिए: इसे इस नियम (srcs से) से संकलित किया जा सकता है या सीधे या ट्रांज़िशन वाली डिपेंडेंसी (runtime_deps या deps के ज़रिए) से उपलब्ध कराया जा सकता है. अगर क्लास उपलब्ध नहीं है, तो बाइनरी रनटाइम के दौरान काम नहीं करेगी; बिल्ड के समय कोई जांच नहीं की जाती.
neverlink	बूलियन; डिफ़ॉल्ट तौर पर False
plugins	लेबल की सूची; डिफ़ॉल्ट [] है कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में बताए गए हर java_plugin को चलाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से प्लग इन भी इनहेरिट हो सकते हैं जो exported_plugins का इस्तेमाल करती हैं. प्लग इन से जनरेट किए गए संसाधन, इस नियम के नतीजे के जार में शामिल किए जाएंगे.
resource_strip_prefix	स्ट्रिंग; डिफ़ॉल्ट रूप से "" Java रिसॉर्स से हटाने के लिए पाथ प्रीफ़िक्स. अगर यह पाथ प्रीफ़िक्स दिया गया है, तो resources एट्रिब्यूट में मौजूद हर फ़ाइल से इसे हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर यह जानकारी नहीं दी गई है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के उसी लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, stuff/java/foo/bar/a.txt पर मौजूद सोर्स फ़ाइल, foo/bar/a.txt पर मौजूद होगी.
runtime_deps	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी लाइब्रेरी जिन्हें फ़ाइनल बाइनरी या सिर्फ़ रनटाइम के दौरान टेस्ट करने के लिए उपलब्ध कराया जाता है. सामान्य deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये deps के उलट, कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी को यहां सूची में शामिल किया जाना चाहिए. डिपेंडेंसी-ऐनालिसिस टूल को उन टारगेट को अनदेखा करना चाहिए जो runtime_deps और deps, दोनों में दिखते हैं.
stamp	पूर्णांक; डिफ़ॉल्ट वैल्यू -1 है बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. वैल्यू, इनमें से कोई हो सकती है: stamp = 1: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. ऐसा --nostamp बिल्ड में भी करें. इस सेटिंग का इस्तेमाल नहीं किया जाना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल नहीं किया जा सकता. stamp = 0: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे, बिल्ड के नतीजे को कैश मेमोरी में सेव करने की सुविधा मिलती है. stamp = -1: बिल्ड की जानकारी को एम्बेड करने की सुविधा को --[no]stamp फ़्लैग से कंट्रोल किया जाता है. स्टैंप की गई बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
use_launcher	बूलियन; डिफ़ॉल्ट तौर पर True बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए या नहीं. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो इस टारगेट के लिए, लॉन्चर एट्रिब्यूट और उससे जुड़े --java_launcher फ़्लैग को अनदेखा कर दिया जाएगा.
use_testrunner	बूलियन; डिफ़ॉल्ट तौर पर 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, add_exports, add_opens, compatible_with, constraints, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, exports, features, jars, licenses, neverlink, package_metadata, proguard_specs, restricted_to, runtime_deps, srcjar, tags, target_compatible_with, testonly, toolchains, visibility)

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

उदाहरण

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

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. java_library.deps देखें.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान, इस नियम के लिए ज़रूरी फ़ाइलों की सूची.
add_exports	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी को दिए गए module या package को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग से जुड़ा है.
add_opens	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी को, दिए गए module या package को रिफ़्लेक्टिव तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग से जुड़ा है.
constraints	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] Java लाइब्रेरी के तौर पर, इस नियम पर अतिरिक्त पाबंदियां लगाई गई हैं.
exports	लेबल की सूची; डिफ़ॉल्ट [] है इस नियम के उपयोगकर्ताओं के लिए उपलब्ध कराने के लिए टारगेट. java_library.exports देखें.
jars	लेबल की सूची; ज़रूरी है इस टारगेट पर निर्भर Java टारगेट के लिए दी गई JAR फ़ाइलों की सूची.
neverlink	बूलियन; डिफ़ॉल्ट तौर पर False इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए करें, न कि रनटाइम के दौरान. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट से, प्रोग्राम के रन होने के दौरान उपलब्ध कराया जाएगा. इस तरह की लाइब्रेरी के उदाहरणों में, IDE प्लग-इन के लिए IDE एपीआई या स्टैंडर्ड JDK पर चलने वाली किसी भी चीज़ के लिए tools.jar शामिल हैं.
proguard_specs	लेबल की सूची; डिफ़ॉल्ट [] है Proguard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनमें, Proguard के इस्तेमाल के लिए स्पेसिफ़िकेशन के सेट के बारे में बताया जाएगा. अगर इनका इस्तेमाल किया जाता है, तो इन्हें इस लाइब्रेरी के आधार पर किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल फ़ाइलों में सिर्फ़ एक जैसे नियम होने चाहिए. जैसे, -dontnote, -dontwarn, assumenosideeffects, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ android_binary के proguard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि टॉटोलॉजिकल मर्ज न हों.
runtime_deps	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी लाइब्रेरी जिन्हें फ़ाइनल बाइनरी या सिर्फ़ रनटाइम के दौरान टेस्ट करने के लिए उपलब्ध कराया जाता है. java_library.runtime_deps देखें.
srcjar	लेबल; डिफ़ॉल्ट रूप से None ऐसी JAR फ़ाइल जिसमें कंपाइल की गई JAR फ़ाइलों का सोर्स कोड होता है.

java_library

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

java_library(name, deps, srcs, data, resources, add_exports, add_opens, bootclasspath, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, exported_plugins, exports, features, javabuilder_jvm_flags, javacopts, licenses, neverlink, package_metadata, plugins, proguard_specs, resource_strip_prefix, restricted_to, runtime_deps, tags, target_compatible_with, testonly, toolchains, visibility)

यह नियम, सोर्स को .jar फ़ाइल में कंपाइल और लिंक करता है.

इंप्लिसिट आउटपुट

• libname.jar: क्लास फ़ाइलों वाला Java संग्रह.
• libname-src.jar: सोर्स ("सोर्स jar") वाला संग्रह.

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी से लिंक की जाने वाली लाइब्रेरी की सूची. deps के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. deps में दिए गए java_library नियमों से बनाए गए jar, इस नियम के संकलन के समय के क्लासपाथ पर होंगे. इसके अलावा, उनके deps, runtime_deps, और exports के ट्रांज़िटिव क्लोज़र, रनटाइम क्लासपाथ पर होंगे. इसके उलट, data एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल होते हैं, लेकिन ये न तो कंपाइल के समय और न ही रनटाइम क्लासपाथ में शामिल होते हैं.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. इस एट्रिब्यूट की वैल्यू सबमिट करना ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, कुछ मामलों में ऐसा नहीं होता. इन अपवादों के बारे में यहां बताया गया है. .java टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई .java फ़ाइलों के लिए, आम तौर पर फ़ाइल के नाम के बजाय, जनरेट करने वाले नियम का नाम यहां डालने का सुझाव दिया जाता है. इससे न सिर्फ़ नियम को पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को ज़्यादा बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम का outs. आपको deps में जनरेट करने वाला नियम नहीं डालना चाहिए, क्योंकि यह कोई काम का नहीं है. .srcjar टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से .java फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर कोई नियम (आम तौर पर genrule या filegroup) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए किया जाता है. .properties टाइप की सोर्स फ़ाइलों को संसाधन माना जाता है. ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद होने पर, बाकी सभी फ़ाइलों को अनदेखा कर दिया जाता है. ऐसा न करने पर, गड़बड़ी का मैसेज दिखता है. runtime_deps आर्ग्युमेंट के अलावा, इस आर्ग्युमेंट की ज़रूरत हमेशा होती है.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. data के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. java_library बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं डालता. अगर data फ़ाइलें जनरेट की गई फ़ाइलें हैं, तो Bazel उन्हें जनरेट करता है. इस java_library पर निर्भर करने वाले किसी जांच को बनाते समय, Bazel data फ़ाइलों को रनफ़ाइल एरिया में कॉपी करता है या लिंक करता है.
resources	लेबल की सूची; डिफ़ॉल्ट [] है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट हुई सामान्य .class फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह लेआउट, "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री के पोते की तरह होता है. अगर वह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन <workspace root>/x/java/y/java/z पर है, तो संसाधन का पाथ y/java/z होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, resource_strip_prefix एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरी डायरेक्ट्री तय की जा सकती है.
add_exports	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी को दिए गए module या package को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग से जुड़ा है.
add_opens	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी को, दिए गए module या package को रिफ़्लेक्टिव तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग से जुड़ा है.
bootclasspath	लेबल; डिफ़ॉल्ट रूप से None प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
exported_plugins	लेबल की सूची; डिफ़ॉल्ट [] है उन लाइब्रेरी में एक्सपोर्ट करने के लिए java_plugins (जैसे, एनोटेशन प्रोसेसर) की सूची जो सीधे इस लाइब्रेरी पर निर्भर करती हैं. java_plugin की बताई गई सूची, उन सभी लाइब्रेरी पर लागू की जाएगी जो सीधे तौर पर इस लाइब्रेरी पर निर्भर करती हैं. ऐसा ठीक वैसे ही होगा जैसे उस लाइब्रेरी ने plugins में इन लेबल का साफ़ तौर पर एलान किया हो.
exports	लेबल की सूची; डिफ़ॉल्ट [] है एक्सपोर्ट की गई लाइब्रेरी. यहां लिस्टिंग के नियमों को शामिल करने से, वे पैरंट रूल के लिए उपलब्ध हो जाएंगे. ऐसा तब होगा, जब पैरंट ने साफ़ तौर पर इन नियमों पर निर्भरता दिखाई हो. यह बात सामान्य (एक्सपोर्ट नहीं किए गए) deps के लिए लागू नहीं होती. खास जानकारी: कोई नियम X, Y में मौजूद कोड को तब ऐक्सेस कर सकता है, जब उनके बीच कोई डिपेंडेंसी पाथ मौजूद हो. यह पाथ, deps एज से शुरू होता है और उसके बाद शून्य या उससे ज़्यादा exports एज होते हैं. आइए, इस बारे में कुछ उदाहरणों की मदद से जानते हैं. मान लें कि A, B पर निर्भर करता है और B, C पर निर्भर करता है. इस मामले में, C, A की ट्रांज़िशन डिपेंडेंसी है. इसलिए, C के सोर्स बदलने और A को फिर से बनाने पर, सब कुछ सही तरीके से फिर से बन जाएगा. हालांकि, A, C में क्लास का इस्तेमाल नहीं कर पाएगा. इसके लिए, A को अपने deps एट्रिब्यूट में 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 में भी इसे शामिल करना होगा.
javabuilder_jvm_flags	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
neverlink	बूलियन; डिफ़ॉल्ट तौर पर False इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए या रनटाइम के दौरान भी. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट से प्रोग्राम के दौरान उपलब्ध कराया जाएगा. इस तरह की लाइब्रेरी के उदाहरणों में, IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चलने वाली किसी भी चीज़ के लिए tools.jar शामिल हैं. ध्यान दें कि neverlink = True, कंपाइलर को इस लाइब्रेरी के कॉन्टेंट को, उस पर निर्भर कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता.ऐसा, Java Language Specification के मुताबिक किया जाता है. उदाहरण के लिए, static final String के कॉन्स्टेंट या प्राइमटिव टाइप के कॉन्स्टेंट). इसलिए, रनटाइम लाइब्रेरी के लिए, संकलन लाइब्रेरी का इस्तेमाल करना बेहतर होता है. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग हो जहां JLS, कंपाइलर को इनलाइन करने से मना करता है. साथ ही, यह JLS के आने वाले सभी वर्शन के लिए भी लागू होना चाहिए.
plugins	लेबल की सूची; डिफ़ॉल्ट [] है कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में बताए गए हर java_plugin को चलाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से प्लग इन भी इनहेरिट हो सकते हैं जो exported_plugins का इस्तेमाल करती हैं. प्लग इन से जनरेट किए गए संसाधन, इस नियम के नतीजे के जार में शामिल किए जाएंगे.
proguard_specs	लेबल की सूची; डिफ़ॉल्ट [] है Proguard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनमें, Proguard के इस्तेमाल के लिए स्पेसिफ़िकेशन के सेट के बारे में बताया जाएगा. अगर इनका इस्तेमाल किया जाता है, तो इन्हें इस लाइब्रेरी के आधार पर किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल फ़ाइलों में सिर्फ़ एक जैसे नियम होने चाहिए. जैसे, -dontnote, -dontwarn, assumenosideeffects, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ android_binary के proguard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि टॉटोलॉजिकल मर्ज न हों.
resource_strip_prefix	स्ट्रिंग; डिफ़ॉल्ट रूप से "" Java रिसॉर्स से हटाने के लिए पाथ प्रीफ़िक्स. अगर यह पाथ प्रीफ़िक्स दिया गया है, तो resources एट्रिब्यूट में मौजूद हर फ़ाइल से इसे हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर यह जानकारी नहीं दी गई है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के उसी लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, stuff/java/foo/bar/a.txt पर मौजूद सोर्स फ़ाइल, foo/bar/a.txt पर मौजूद होगी.
runtime_deps	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी लाइब्रेरी जिन्हें फ़ाइनल बाइनरी या सिर्फ़ रनटाइम के दौरान टेस्ट करने के लिए उपलब्ध कराया जाता है. सामान्य deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये deps के उलट, कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी को यहां सूची में शामिल किया जाना चाहिए. डिपेंडेंसी-ऐनालिसिस टूल को उन टारगेट को अनदेखा करना चाहिए जो runtime_deps और deps, दोनों में दिखते हैं.

java_test

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

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

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

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

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

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

उदाहरण

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

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

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट से लिंक की जाने वाली अन्य लाइब्रेरी की सूची. deps के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. इस एट्रिब्यूट की वैल्यू सबमिट करना ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, कुछ मामलों में ऐसा नहीं होता. इन अपवादों के बारे में यहां बताया गया है. .java टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई .java फ़ाइलों के लिए, आम तौर पर फ़ाइल के नाम के बजाय, जनरेट करने वाले नियम का नाम यहां डालने का सुझाव दिया जाता है. इससे न सिर्फ़ नियम को पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को ज़्यादा बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम का outs. आपको deps में जनरेट करने वाला नियम नहीं डालना चाहिए, क्योंकि यह कोई काम का नहीं है. .srcjar टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से .java फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर कोई नियम (आम तौर पर genrule या filegroup) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए किया जाता है. यह आर्ग्युमेंट ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, अगर main_class एट्रिब्यूट, रनटाइम क्लासपाथ पर किसी क्लास की जानकारी देता है या आपने runtime_deps आर्ग्युमेंट दिया है, तो यह ज़रूरी नहीं है.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. data के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं.
resources	लेबल की सूची; डिफ़ॉल्ट [] है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट हुई सामान्य .class फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह लेआउट, "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री के पोते की तरह होता है. अगर वह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन <workspace root>/x/java/y/java/z पर है, तो संसाधन का पाथ y/java/z होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, resource_strip_prefix एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरी डायरेक्ट्री तय की जा सकती है.
add_exports	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी को दिए गए module या package को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग से जुड़ा है.
add_opens	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी को, दिए गए module या package को रिफ़्लेक्टिव तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग से जुड़ा है.
bootclasspath	लेबल; डिफ़ॉल्ट रूप से None प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
classpath_resources	लेबल की सूची; डिफ़ॉल्ट [] है इस विकल्प का इस्तेमाल तब तक न करें, जब तक कोई दूसरा विकल्प न हो) उन संसाधनों की सूची जो जावा ट्री के रूट में मौजूद होने चाहिए. इस एट्रिब्यूट का एक ही मकसद है, तीसरे पक्ष की उन लाइब्रेरी के साथ काम करना जिनके लिए ज़रूरी है कि उनके रिसॉर्स, क्लासपाथ पर "myconfig.xml" के तौर पर मिलें. नेमस्पेस के टकराव की आशंका की वजह से, इसे सिर्फ़ बाइनरी पर इस्तेमाल करने की अनुमति है, न कि लाइब्रेरी पर.
create_executable	बूलियन; डिफ़ॉल्ट तौर पर True इस्तेमाल नहीं किया जा सकता. इसके बजाय, java_single_jar का इस्तेमाल करें.
deploy_manifest_lines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] *_deploy.jar टारगेट के लिए जनरेट की गई META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची. इस एट्रिब्यूट के कॉन्टेंट में, "वैरिएबल बनाएं" विकल्प का इस्तेमाल करके बदलाव नहीं किया जा सकता.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस बाइनरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
jvm_flags	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस बाइनरी को चलाने के लिए जनरेट की गई रैपर स्क्रिप्ट में जोड़ने के लिए फ़्लैग की सूची. $(location) और "Make variable" के बदले, और Bourne shell tokenization के हिसाब से. Java बाइनरी के लिए रैपर स्क्रिप्ट में CLASSPATH परिभाषा शामिल होती है, ताकि सभी डिपेंडेंट (आश्रित) jar ढूंढे जा सकें. साथ ही, यह सही Java इंटरप्रेटर को भी चालू करती है. रैपर स्क्रिप्ट से जनरेट की गई कमांड लाइन में, मुख्य क्लास का नाम और उसके बाद "$@" होता है, ताकि क्लास के नाम के बाद अन्य आर्ग्युमेंट पास किए जा सकें. हालांकि, JVM के पास पार्स करने के लिए जिन आर्ग्युमेंट का इस्तेमाल करना है उन्हें कमांड लाइन पर क्लास के नाम से पहले तय करना होगा. क्लास का नाम सूची में शामिल होने से पहले, jvm_flags के कॉन्टेंट को रैपर स्क्रिप्ट में जोड़ दिया जाता है. ध्यान दें कि इस एट्रिब्यूट का *_deploy.jar आउटपुट पर कोई असर नहीं पड़ता.
launcher	लेबल; डिफ़ॉल्ट रूप से None JDK में शामिल सामान्य bin/java प्रोग्राम के बजाय, अपने Java प्रोग्राम को चलाने के लिए इस्तेमाल किए जाने वाले बाइनरी को तय करें. टारगेट एक cc_binary होना चाहिए. इस एट्रिब्यूट की वैल्यू के तौर पर, Java Invocation API को लागू करने वाला कोई भी cc_binary दिया जा सकता है. डिफ़ॉल्ट रूप से, Bazel सामान्य JDK लॉन्चर (bin/java या java.exe) का इस्तेमाल करेगा. इससे जुड़े --java_launcher Bazel फ़्लैग का असर सिर्फ़ उन java_binary और java_test टारगेट पर पड़ता है जिनके लिए launcher एट्रिब्यूट की वैल्यू न दी गई है. ध्यान दें कि JDK लॉन्चर या किसी अन्य लॉन्चर का इस्तेमाल करने पर, आपकी नेटिव (C++, SWIG, JNI) डिपेंडेंसी अलग-अलग तरीके से बनाई जाएंगी: अगर सामान्य JDK लॉन्चर (डिफ़ॉल्ट) का इस्तेमाल किया जा रहा है, तो नेटिव डिपेंडेंसी को {name}_nativedeps.so नाम की शेयर की गई लाइब्रेरी के तौर पर बनाया जाता है. यहां {name}, इस java_binary नियम का name एट्रिब्यूट है. इस कॉन्फ़िगरेशन में, लिंकर इस्तेमाल न किए गए कोड को नहीं हटाता. अगर किसी दूसरे लॉन्चर का इस्तेमाल किया जा रहा है, तो नेटिव (C++) डिपेंडेंसी को {name}_nativedeps नाम के बाइनरी में स्टैटिक तौर पर लिंक किया जाता है. यहां {name}, इस java_binary नियम का name एट्रिब्यूट है. इस मामले में, लिंकर उस कोड को हटा देगा जो उसके हिसाब से, बाइनरी में इस्तेमाल नहीं किया गया है. इसका मतलब है कि सिर्फ़ JNI के ज़रिए ऐक्सेस किया गया कोई भी C++ कोड तब तक लिंक नहीं किया जा सकता, जब तक कि cc_library टारगेट में alwayslink = True की जानकारी न दी गई हो. डिफ़ॉल्ट JDK लॉन्चर के अलावा किसी दूसरे लॉन्चर का इस्तेमाल करने पर, *_deploy.jar आउटपुट का फ़ॉर्मैट बदल जाता है. ज़्यादा जानकारी के लिए, मुख्य java_binary दस्तावेज़ देखें.
main_class	स्ट्रिंग; डिफ़ॉल्ट रूप से "" एंट्री पॉइंट के तौर पर इस्तेमाल करने के लिए, main() तरीके वाली क्लास का नाम. अगर कोई नियम इस विकल्प का इस्तेमाल करता है, तो उसे srcs=[...] सूची की ज़रूरत नहीं होती. इस एट्रिब्यूट की मदद से, किसी ऐसी Java लाइब्रेरी से एक ऐसी एक्सीक्यूटेबल बनाई जा सकती है जिसमें पहले से ही एक या उससे ज़्यादा main() तरीके मौजूद हों. इस एट्रिब्यूट की वैल्यू, सोर्स फ़ाइल नहीं, बल्कि क्लास का नाम होती है. क्लास, रनटाइम के दौरान उपलब्ध होनी चाहिए: इसे इस नियम (srcs से) से संकलित किया जा सकता है या सीधे या ट्रांज़िशन वाली डिपेंडेंसी (runtime_deps या deps के ज़रिए) से उपलब्ध कराया जा सकता है. अगर क्लास उपलब्ध नहीं है, तो बाइनरी रनटाइम के दौरान काम नहीं करेगी; बिल्ड के समय कोई जांच नहीं की जाती.
neverlink	बूलियन; डिफ़ॉल्ट तौर पर False
plugins	लेबल की सूची; डिफ़ॉल्ट [] है कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में बताए गए हर java_plugin को चलाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से प्लग इन भी इनहेरिट हो सकते हैं जो exported_plugins का इस्तेमाल करती हैं. प्लग इन से जनरेट किए गए संसाधन, इस नियम के नतीजे के जार में शामिल किए जाएंगे.
resource_strip_prefix	स्ट्रिंग; डिफ़ॉल्ट रूप से "" Java रिसॉर्स से हटाने के लिए पाथ प्रीफ़िक्स. अगर यह पाथ प्रीफ़िक्स दिया गया है, तो resources एट्रिब्यूट में मौजूद हर फ़ाइल से इसे हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर यह जानकारी नहीं दी गई है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के उसी लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, stuff/java/foo/bar/a.txt पर मौजूद सोर्स फ़ाइल, foo/bar/a.txt पर मौजूद होगी.
runtime_deps	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी लाइब्रेरी जिन्हें फ़ाइनल बाइनरी या सिर्फ़ रनटाइम के दौरान टेस्ट करने के लिए उपलब्ध कराया जाता है. सामान्य deps की तरह, ये रनटाइम क्लासपाथ पर दिखेंगे. हालांकि, ये deps के उलट, कंपाइल-टाइम क्लासपाथ पर नहीं दिखेंगे. सिर्फ़ रनटाइम पर ज़रूरी डिपेंडेंसी को यहां सूची में शामिल किया जाना चाहिए. डिपेंडेंसी-ऐनालिसिस टूल को उन टारगेट को अनदेखा करना चाहिए जो runtime_deps और deps, दोनों में दिखते हैं.
stamp	पूर्णांक; डिफ़ॉल्ट वैल्यू 0 है बिल्ड की जानकारी को बाइनरी में एन्कोड करना है या नहीं. वैल्यू, इनमें से कोई हो सकती है: stamp = 1: बिल्ड की जानकारी को हमेशा बाइनरी में स्टैंप करें. ऐसा --nostamp बिल्ड में भी करें. इस सेटिंग का इस्तेमाल नहीं किया जाना चाहिए, क्योंकि इससे बाइनरी और उस पर निर्भर सभी डाउनस्ट्रीम ऐक्शन के लिए, रिमोट कैश मेमोरी का इस्तेमाल नहीं किया जा सकता. stamp = 0: हमेशा बिल्ड की जानकारी को कॉन्स्टेंट वैल्यू से बदलें. इससे, बिल्ड के नतीजे को कैश मेमोरी में सेव करने की सुविधा मिलती है. stamp = -1: बिल्ड की जानकारी को एम्बेड करने की सुविधा को --[no]stamp फ़्लैग से कंट्रोल किया जाता है. स्टैंप की गई बाइनरी को तब तक फिर से नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी में बदलाव न हो.
test_class	स्ट्रिंग; डिफ़ॉल्ट रूप से "" टेस्ट रनर से लोड की जाने वाली Java क्लास. डिफ़ॉल्ट रूप से, अगर इस आर्ग्युमेंट की जानकारी नहीं दी गई है, तो लेगसी मोड का इस्तेमाल किया जाता है और इसके बजाय, टेस्ट आर्ग्युमेंट का इस्तेमाल किया जाता है. पहले आर्ग्युमेंट पर फ़ॉलबैक न करने के लिए, --nolegacy_bazel_java_test फ़्लैग सेट करें. इस एट्रिब्यूट से, उस Java क्लास का नाम पता चलता है जिसे इस टेस्ट से चलाया जाना है. आम तौर पर, इसे सेट करने की ज़रूरत नहीं होती. अगर इस आर्ग्युमेंट को छोड़ा जाता है, तो इसे टारगेट के name और उसके सोर्स-रूट-रिलेटिव पाथ का इस्तेमाल करके अनुमान लगाया जाएगा. अगर टेस्ट किसी जाने-पहचाने test_class सोर्स रूट के बाहर है, तो Bazel गड़बड़ी की रिपोर्ट करेगा. JUnit3 के लिए, टेस्ट क्लास को junit.framework.TestCase का सबक्लास होना चाहिए या फिर उसमें ऐसा सार्वजनिक स्टैटिक suite() मैथड होना चाहिए जो junit.framework.Test (या Test का सबक्लास) दिखाता हो. इस एट्रिब्यूट की मदद से, कई java_test नियमों के लिए एक ही Test (TestCase, TestSuite, ...) शेयर किया जा सकता है. आम तौर पर, इसमें ज़्यादा जानकारी (जैसे, jvm_flags=['-Dkey=value'] के ज़रिए) दी जाती है, ताकि हर मामले में इसका व्यवहार अलग हो. जैसे, टेस्ट का कोई दूसरा सबसेट चलाना. इस एट्रिब्यूट की मदद से, javatests ट्री के बाहर भी Java टेस्ट का इस्तेमाल किया जा सकता है.
use_launcher	बूलियन; डिफ़ॉल्ट तौर पर True बाइनरी को कस्टम लॉन्चर का इस्तेमाल करना चाहिए या नहीं. अगर इस एट्रिब्यूट को 'गलत है' पर सेट किया जाता है, तो इस टारगेट के लिए, लॉन्चर एट्रिब्यूट और उससे जुड़े --java_launcher फ़्लैग को अनदेखा कर दिया जाएगा.
use_testrunner	बूलियन; डिफ़ॉल्ट तौर पर True किसी Java प्रोग्राम के मुख्य एंट्री पॉइंट के तौर पर, टेस्ट रनर (डिफ़ॉल्ट रूप से com.google.testing.junit.runner.BazelTestRunner) क्लास का इस्तेमाल करें. साथ ही, टेस्ट रनर को bazel.test_suite सिस्टम प्रॉपर्टी की वैल्यू के तौर पर टेस्ट क्लास दें. इसका इस्तेमाल, डिफ़ॉल्ट व्यवहार को बदलने के लिए किया जा सकता है. डिफ़ॉल्ट तौर पर, java_test नियमों के लिए टेस्ट रननर का इस्तेमाल किया जाता है और java_binary नियमों के लिए इसका इस्तेमाल नहीं किया जाता. ऐसा होने की संभावना कम है. इसका एक इस्तेमाल, AllTest उन नियमों के लिए किया जाता है जिन्हें किसी दूसरे नियम से चालू किया जाता है. उदाहरण के लिए, जांच चलाने से पहले डेटाबेस सेट अप करने के लिए. AllTest नियम को java_binary के तौर पर घोषित किया जाना चाहिए. हालांकि, इसके लिए अब भी टेस्ट रनर को मुख्य एंट्री पॉइंट के तौर पर इस्तेमाल करना चाहिए. टेस्ट रनर क्लास के नाम को main_class एट्रिब्यूट की मदद से बदला जा सकता है.

java_package_configuration

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

java_package_configuration(name, data, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, javacopts, output_licenses, package_metadata, packages, restricted_to, system, tags, target_compatible_with, testonly, toolchains, visibility)

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

उदाहरण:

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

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

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

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान, इस कॉन्फ़िगरेशन के लिए ज़रूरी फ़ाइलों की सूची.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] Java कंपाइलर फ़्लैग.
output_licenses	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []
packages	लेबल की सूची; डिफ़ॉल्ट [] है package_group का वह सेट जिस पर कॉन्फ़िगरेशन लागू करना है.
system	लेबल; डिफ़ॉल्ट रूप से None यह javac के --system फ़्लैग से मेल खाता है.

java_plugin

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

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

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

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

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

आर्ग्युमेंट, processor_class और generates_api आर्ग्युमेंट को छोड़कर, java_library() के आर्ग्युमेंट के सबसेट होते हैं. साथ ही, इनका सेमेटिक भी एक जैसा होता है.

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है इस लाइब्रेरी से लिंक की जाने वाली लाइब्रेरी की सूची. deps के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. deps में दिए गए java_library नियमों से बनाए गए jar, इस नियम के संकलन के समय के क्लासपाथ पर होंगे. इसके अलावा, उनके deps, runtime_deps, और exports के ट्रांज़िटिव क्लोज़र, रनटाइम क्लासपाथ पर होंगे. इसके उलट, data एट्रिब्यूट में मौजूद टारगेट, रनफ़ाइल में शामिल होते हैं, लेकिन ये न तो कंपाइल के समय और न ही रनटाइम क्लासपाथ में शामिल होते हैं.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है टारगेट बनाने के लिए प्रोसेस की गई सोर्स फ़ाइलों की सूची. इस एट्रिब्यूट की वैल्यू सबमिट करना ज़्यादातर मामलों में ज़रूरी होता है. हालांकि, कुछ मामलों में ऐसा नहीं होता. इन अपवादों के बारे में यहां बताया गया है. .java टाइप की सोर्स फ़ाइलें कंपाइल की जाती हैं. जनरेट की गई .java फ़ाइलों के लिए, आम तौर पर फ़ाइल के नाम के बजाय, जनरेट करने वाले नियम का नाम यहां डालने का सुझाव दिया जाता है. इससे न सिर्फ़ नियम को पढ़ने में आसानी होती है, बल्कि आने वाले समय में होने वाले बदलावों के हिसाब से नियम को ज़्यादा बेहतर बनाया जा सकता है: अगर जनरेट करने वाला नियम आने वाले समय में अलग-अलग फ़ाइलें जनरेट करता है, तो आपको सिर्फ़ एक जगह ठीक करनी होगी: जनरेट करने वाले नियम का outs. आपको deps में जनरेट करने वाला नियम नहीं डालना चाहिए, क्योंकि यह कोई काम का नहीं है. .srcjar टाइप की सोर्स फ़ाइलों को अनपैक और कंपाइल किया जाता है. (यह तब काम आता है, जब आपको genrule की मदद से .java फ़ाइलों का सेट जनरेट करना हो.) नियम: अगर कोई नियम (आम तौर पर genrule या filegroup) ऊपर दी गई किसी भी फ़ाइल को जनरेट करता है, तो उसका इस्तेमाल उसी तरह किया जाएगा जिस तरह सोर्स फ़ाइलों के लिए किया जाता है. .properties टाइप की सोर्स फ़ाइलों को संसाधन माना जाता है. ऊपर बताए गए फ़ाइल टाइप की कम से कम एक फ़ाइल मौजूद होने पर, बाकी सभी फ़ाइलों को अनदेखा कर दिया जाता है. ऐसा न करने पर, गड़बड़ी का मैसेज दिखता है. runtime_deps आर्ग्युमेंट के अलावा, इस आर्ग्युमेंट की ज़रूरत हमेशा होती है.
data	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम के दौरान, इस लाइब्रेरी को जिन फ़ाइलों की ज़रूरत होती है उनकी सूची. data के बारे में सामान्य टिप्पणियां देखने के लिए, ज़्यादातर बिल्ड नियमों के मुताबिक तय किए गए सामान्य एट्रिब्यूट पर जाएं. java_library बनाते समय, Bazel इन फ़ाइलों को कहीं भी नहीं डालता. अगर data फ़ाइलें जनरेट की गई फ़ाइलें हैं, तो Bazel उन्हें जनरेट करता है. इस java_library पर निर्भर करने वाले किसी जांच को बनाते समय, Bazel data फ़ाइलों को रनफ़ाइल एरिया में कॉपी करता है या लिंक करता है.
resources	लेबल की सूची; डिफ़ॉल्ट [] है Java jar में शामिल करने के लिए डेटा फ़ाइलों की सूची. संसाधन, सोर्स फ़ाइलें या जनरेट की गई फ़ाइलें हो सकती हैं. अगर संसाधनों की जानकारी दी गई है, तो उन्हें कंपाइल करने पर जनरेट हुई सामान्य .class फ़ाइलों के साथ, jar में बंडल किया जाएगा. प्रोजेक्ट के स्ट्रक्चर से यह तय होता है कि jar फ़ाइल में रिसॉर्स कहां मौजूद होंगे. Bazel सबसे पहले Maven के स्टैंडर्ड डायरेक्ट्री लेआउट को खोजता है. यह लेआउट, "src" डायरेक्ट्री के बाद "resources" डायरेक्ट्री के पोते की तरह होता है. अगर वह नहीं मिलता है, तो Bazel "java" या "javatests" नाम की सबसे ऊपर मौजूद डायरेक्ट्री खोजता है. उदाहरण के लिए, अगर कोई संसाधन <workspace root>/x/java/y/java/z पर है, तो संसाधन का पाथ y/java/z होगा. इस हेयुरिस्टिक्स को बदला नहीं जा सकता. हालांकि, resource_strip_prefix एट्रिब्यूट का इस्तेमाल करके, संसाधन फ़ाइलों के लिए कोई दूसरी डायरेक्ट्री तय की जा सकती है.
add_exports	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी को दिए गए module या package को ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-exports= फ़्लैग से जुड़ा है.
add_opens	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी को, दिए गए module या package को रिफ़्लेक्टिव तरीके से ऐक्सेस करने की अनुमति दें. यह javac और JVM --add-opens= फ़्लैग से जुड़ा है.
bootclasspath	लेबल; डिफ़ॉल्ट रूप से None प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
generates_api	बूलियन; डिफ़ॉल्ट तौर पर False यह एट्रिब्यूट, एनोटेशन प्रोसेसर को मार्क करता है, जो एपीआई कोड जनरेट करते हैं. अगर कोई नियम, एपीआई जनरेट करने वाले एनोटेशन प्रोसेसर का इस्तेमाल करता है, तो उस पर निर्भर अन्य नियम, जनरेट किए गए कोड का रेफ़रंस सिर्फ़ तब दे सकते हैं, जब उनके कोड कंपाइल करने की कार्रवाइयां, जनरेट करने वाले नियम के बाद शेड्यूल की गई हों. यह एट्रिब्यूट, Bazel को शेड्यूलिंग से जुड़ी पाबंदियां लागू करने का निर्देश देता है. ऐसा तब होता है, जब --java_header_compilation चालू हो. चेतावनी: इस एट्रिब्यूट का असर, बिल्ड की परफ़ॉर्मेंस पर पड़ता है. इसलिए, इसका इस्तेमाल सिर्फ़ ज़रूरत पड़ने पर करें.
javabuilder_jvm_flags	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] प्रतिबंधित एपीआई, इसका इस्तेमाल न करें!
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस लाइब्रेरी के लिए कंपाइलर के अतिरिक्त विकल्प. "Make variable" के बदले और Bourne shell टोकनाइज़ेशन के हिसाब से. कंपाइलर के ये विकल्प, ग्लोबल कंपाइलर विकल्पों के बाद javac को पास किए जाते हैं.
neverlink	बूलियन; डिफ़ॉल्ट तौर पर False इस लाइब्रेरी का इस्तेमाल सिर्फ़ कंपाइलेशन के लिए किया जाना चाहिए या रनटाइम के दौरान भी. यह तब काम का होता है, जब लाइब्रेरी को रनटाइम एनवायरमेंट से प्रोग्राम के दौरान उपलब्ध कराया जाएगा. इस तरह की लाइब्रेरी के उदाहरणों में, IDE प्लग-इन के लिए IDE API या स्टैंडर्ड JDK पर चलने वाली किसी भी चीज़ के लिए tools.jar शामिल हैं. ध्यान दें कि neverlink = True, कंपाइलर को इस लाइब्रेरी के कॉन्टेंट को, उस पर निर्भर कंपाइलेशन टारगेट में इनलाइन करने से नहीं रोकता.ऐसा, Java Language Specification के मुताबिक किया जाता है. उदाहरण के लिए, static final String के कॉन्स्टेंट या प्राइमटिव टाइप के कॉन्स्टेंट). इसलिए, रनटाइम लाइब्रेरी के लिए, संकलन लाइब्रेरी का इस्तेमाल करना बेहतर होता है. अगर रनटाइम लाइब्रेरी, कंपाइलेशन लाइब्रेरी से अलग है, तो आपको यह पक्का करना होगा कि यह सिर्फ़ उन जगहों पर अलग हो जहां JLS, कंपाइलर को इनलाइन करने से मना करता है. साथ ही, यह JLS के आने वाले सभी वर्शन के लिए भी लागू होना चाहिए.
output_licenses	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []
plugins	लेबल की सूची; डिफ़ॉल्ट [] है कंपाइल के समय चलने वाले Java कंपाइलर प्लग इन. जब भी यह नियम बनाया जाएगा, तब इस एट्रिब्यूट में बताए गए हर java_plugin को चलाया जाएगा. लाइब्रेरी को उन डिपेंडेंसी से प्लग इन भी इनहेरिट हो सकते हैं जो exported_plugins का इस्तेमाल करती हैं. प्लग इन से जनरेट किए गए संसाधन, इस नियम के नतीजे के जार में शामिल किए जाएंगे.
processor_class	स्ट्रिंग; डिफ़ॉल्ट रूप से "" प्रोसेसर क्लास, क्लास का पूरी तरह से क्वालिफ़ाइड टाइप है. Java कंपाइलर को एनोटेशन प्रोसेसर के एंट्री पॉइंट के तौर पर इसका इस्तेमाल करना चाहिए. अगर इसकी जानकारी नहीं दी जाती है, तो यह नियम, Java कंपाइलर के एनोटेशन प्रोसेसिंग में एनोटेशन प्रोसेसर का योगदान नहीं देगा. हालांकि, इसके रनटाइम क्लासपाथ को अब भी कंपाइलर के एनोटेशन प्रोसेसर पाथ में शामिल किया जाएगा. (इसका मुख्य मकसद, ऐसे प्लग इन का इस्तेमाल करना है जिनमें गड़बड़ी होने की संभावना ज़्यादा होती है. इन्हें एनोटेशन प्रोसेसर पाथ से लोड किया जाता है. इसके लिए, java.util.ServiceLoader का इस्तेमाल किया जाता है.)
proguard_specs	लेबल की सूची; डिफ़ॉल्ट [] है Proguard स्पेसिफ़िकेशन के तौर पर इस्तेमाल की जाने वाली फ़ाइलें. इनमें, Proguard के इस्तेमाल के लिए स्पेसिफ़िकेशन के सेट के बारे में बताया जाएगा. अगर इनका इस्तेमाल किया जाता है, तो इन्हें इस लाइब्रेरी के आधार पर किसी भी android_binary टारगेट में जोड़ दिया जाएगा. यहां शामिल फ़ाइलों में सिर्फ़ एक जैसे नियम होने चाहिए. जैसे, -dontnote, -dontwarn, assumenosideeffects, और -keep से शुरू होने वाले नियम. अन्य विकल्प सिर्फ़ android_binary के proguard_specs में दिख सकते हैं, ताकि यह पक्का किया जा सके कि टॉटोलॉजिकल मर्ज न हों.
resource_strip_prefix	स्ट्रिंग; डिफ़ॉल्ट रूप से "" Java रिसॉर्स से हटाने के लिए पाथ प्रीफ़िक्स. अगर यह पाथ प्रीफ़िक्स दिया गया है, तो resources एट्रिब्यूट में मौजूद हर फ़ाइल से इसे हटा दिया जाता है. अगर कोई संसाधन फ़ाइल इस डायरेक्ट्री में नहीं है, तो यह गड़बड़ी है. अगर यह जानकारी नहीं दी गई है (डिफ़ॉल्ट), तो संसाधन फ़ाइल का पाथ, सोर्स फ़ाइलों के Java पैकेज के उसी लॉजिक के हिसाब से तय किया जाता है. उदाहरण के लिए, stuff/java/foo/bar/a.txt पर मौजूद सोर्स फ़ाइल, foo/bar/a.txt पर मौजूद होगी.

java_runtime

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

java_runtime(name, srcs, compatible_with, default_cds, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, hermetic_srcs, hermetic_static_libs, java, java_home, lib_ct_sym, lib_modules, output_licenses, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, version, visibility)

Java रनटाइम के कॉन्फ़िगरेशन के बारे में बताता है.

उदाहरण:

java_runtime(
    name = "jdk-9-ea+153",
    srcs = glob(["jdk9-ea+153/**"]),
    java_home = "jdk9-ea+153",
)

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
srcs	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम में मौजूद सभी फ़ाइलें.
default_cds	लेबल; डिफ़ॉल्ट रूप से None पूरी तरह से सुरक्षित java_runtime के लिए, सीडीएस का डिफ़ॉल्ट संग्रह. जब किसी java_binary टारगेट के लिए, हेर्मेटिक मोड चालू होता है, तो java_runtime डिफ़ॉल्ट सीडीएस को हेर्मेटिक डिप्लॉय JAR में पैकेज किया जाता है.
hermetic_srcs	लेबल की सूची; डिफ़ॉल्ट [] है रनटाइम में मौजूद फ़ाइलें, जो पूरी तरह से सुरक्षित डिप्लॉयमेंट के लिए ज़रूरी हैं.
hermetic_static_libs	लेबल की सूची; डिफ़ॉल्ट [] है ऐसी लाइब्रेरी जो पूरी तरह से सुरक्षित डिप्लॉयमेंट के लिए, लॉन्चर के साथ स्टैटिक तौर पर लिंक होती हैं
java	लेबल; डिफ़ॉल्ट रूप से None Java की एक्ज़ीक्यूट की जा सकने वाली फ़ाइल का पाथ.
java_home	स्ट्रिंग; डिफ़ॉल्ट रूप से "" रनटाइम के रूट का पाथ. "Make" वैरिएबल के बदले इस्तेमाल किया जा सकता है. अगर यह पाथ एब्सोलूट है, तो नियम से पता चलता है कि यह एक ऐसा Java रनटाइम है जो पूरी तरह से सुरक्षित नहीं है और जिसका पाथ आम तौर पर जाना जाता है. ऐसे में, srcs और java एट्रिब्यूट की वैल्यू खाली होनी चाहिए.
lib_ct_sym	लेबल; डिफ़ॉल्ट रूप से None --release के साथ कंपाइल करने के लिए, lib/ct.sym फ़ाइल की ज़रूरत होती है. अगर फ़ाइल का पाथ नहीं दिया गया है और srcs में ऐसी एक फ़ाइल है जिसका पाथ /lib/ct.sym पर खत्म होता है, तो उस फ़ाइल का इस्तेमाल किया जाता है.
lib_modules	लेबल; डिफ़ॉल्ट रूप से None हेर्मेटिक डिप्लॉयमेंट के लिए, lib/modules फ़ाइल ज़रूरी है.
output_licenses	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []
version	पूर्णांक; डिफ़ॉल्ट वैल्यू 0 है Java रनटाइम की सुविधा का वर्शन. इसका मतलब है कि Runtime.version().feature() से मिलने वाला पूर्णांक.

java_single_jar

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

java_single_jar(name, deps, compatible_with, compress, deploy_env, deploy_manifest_lines, deprecation, exclude_build_data, exec_compatible_with, exec_group_compatible_with, exec_properties, features, multi_release, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

Java की डिपेंडेंसी और jar फ़ाइलों को एक ही jar में इकट्ठा करता है `java_single_jar`, Java की डिपेंडेंसी और jar फ़ाइलों को एक ही jar में इकट्ठा करता है. यह java_binary से मिलता-जुलता है, जिसमें सभी एक्सीक्यूटेबल बंद होते हैं. साथ ही, यह java_binary "डिप्लॉय jar हैक" का विकल्प भी उपलब्ध कराता है. ## उदाहरण ```skylark load("//tools/build_defs/java_single_jar:java_single_jar.bzl", "java_single_jar") java_single_jar( name = "my_single_jar", deps = [ "//java/com/google/foo", "//java/com/google/bar", ], ) ``` आउटपुट: {name}.jar: एक ऐसा jar जिसमें सभी इनपुट शामिल होते हैं.

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
deps	लेबल की सूची; डिफ़ॉल्ट [] है ट्रांज़िटिव डिपेंडेंसी इकट्ठा करने के लिए, Java टारगेट (इनमें java_import और java_library शामिल हैं). रनटाइम डिपेंडेंसी, deps, exports, और runtime_deps के ज़रिए इकट्ठा की जाती हैं. संसाधन भी इकट्ठा किए जाते हैं. नेटिव cc_library या java_wrap_cc डिपेंडेंसी नहीं हैं.
compress	स्ट्रिंग; डिफ़ॉल्ट रूप से "preserve" हमेशा डिफ़्लेट करें ("हां"), हमेशा सेव करें ("नहीं") या बिना बदलाव के पास करें ("बचाना"). डिफ़ॉल्ट रूप से, "बचत करें" विकल्प चुना जाता है. यह सबसे बेहतर विकल्प है. इसमें, डेटा को बड़ा या छोटा करने के लिए कोई अतिरिक्त काम नहीं किया जाता.
deploy_env	लेबल की सूची; डिफ़ॉल्ट [] है `java_binary` या `java_single_jar` टारगेट की सूची, जो इस बाइनरी के लिए डिप्लॉयमेंट एनवायरमेंट दिखाती है. इस एट्रिब्यूट को किसी ऐसे प्लग इन को बनाते समय सेट करें जिसे किसी दूसरे `java_binary` से लोड किया जाएगा. इस नियम से बनाए गए jar से, `deploy_env` डिपेंडेंसी को बाहर रखा जाता है.
deploy_manifest_lines	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] META-INF/manifest.mf फ़ाइल में जोड़ने के लिए लाइनों की सूची.
exclude_build_data	बूलियन; डिफ़ॉल्ट तौर पर True डिफ़ॉल्ट रूप से जनरेट की गई build-data.properties फ़ाइल को शामिल करना है या नहीं.
multi_release	बूलियन; डिफ़ॉल्ट तौर पर True एक से ज़्यादा रिलीज़ वाले आउटपुट जार चालू करने हैं या नहीं.

java_toolchain

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

java_toolchain(name, android_lint_data, android_lint_jvm_opts, android_lint_opts, android_lint_package_configuration, android_lint_runner, bootclasspath, compatible_javacopts, compatible_with, deprecation, deps_checker, exec_compatible_with, exec_group_compatible_with, exec_properties, features, forcibly_disable_header_compilation, genclass, header_compiler, header_compiler_builtin_processors, header_compiler_direct, ijar, jacocorunner, java_runtime, javabuilder, javabuilder_data, javabuilder_jvm_opts, javac_supports_multiplex_workers, javac_supports_worker_cancellation, javac_supports_worker_multiplex_sandboxing, javac_supports_workers, javacopts, jspecify_implicit_deps, jspecify_javacopts, jspecify_packages, jspecify_processor, jspecify_processor_class, jspecify_stubs, jvm_opts, licenses, misc, oneversion, oneversion_allowlist, oneversion_allowlist_for_tests, oneversion_whitelist, package_configuration, package_metadata, proguard_allowlister, reduced_classpath_incompatible_processors, restricted_to, singlejar, source_version, tags, target_compatible_with, target_version, testonly, timezone_data, toolchains, tools, turbine_data, turbine_jvm_opts, visibility, xlint)

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

उदाहरण

इसका एक आसान उदाहरण यह है:

java_toolchain(
    name = "toolchain",
    source_version = "7",
    target_version = "7",
    bootclasspath = ["//tools/jdk:bootclasspath"],
    xlint = [ "classfile", "divzero", "empty", "options", "path" ],
    javacopts = [ "-g" ],
    javabuilder = ":JavaBuilder_deploy.jar",
)

तर्क

विशेषताएं
name	नाम; यह ज़रूरी है इस टारगेट के लिए यूनीक नाम.
android_lint_data	लेबल की सूची; डिफ़ॉल्ट [] है android_lint_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध टूल के लेबल.
android_lint_jvm_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] Android Lint को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची.
android_lint_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] Android Lint के आर्ग्युमेंट की सूची.
android_lint_package_configuration	लेबल की सूची; डिफ़ॉल्ट [] है Android Lint कॉन्फ़िगरेशन, जिसे बताए गए पैकेज ग्रुप पर लागू किया जाना चाहिए.
android_lint_runner	लेबल; डिफ़ॉल्ट रूप से None Android Lint Runner का लेबल, अगर कोई है.
bootclasspath	लेबल की सूची; डिफ़ॉल्ट [] है Java टारगेट के bootclasspath की एंट्री. यह javac के -bootclasspath फ़्लैग से मेल खाता है.
compatible_javacopts	null; डिफ़ॉल्ट {} है इंटरनल एपीआई, इसका इस्तेमाल न करें!
deps_checker	लेबल; डिफ़ॉल्ट रूप से None ImportDepsChecker डिप्लॉय किए गए jar का लेबल.
forcibly_disable_header_compilation	बूलियन; डिफ़ॉल्ट तौर पर False यह --java_header_compilation को बदल देता है, ताकि उन प्लैटफ़ॉर्म पर हेडर कंपाइलेशन की सुविधा बंद की जा सके जिन पर यह काम नहीं करता. जैसे, JDK 7 Bazel.
genclass	लेबल; डिफ़ॉल्ट रूप से None GenClass डिप्लॉय किए गए jar का लेबल.
header_compiler	लेबल; डिफ़ॉल्ट रूप से None हेडर कंपाइलर का लेबल. --java_header_compilation चालू होने पर ज़रूरी है.
header_compiler_builtin_processors	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इंटरनल एपीआई, इसका इस्तेमाल न करें!
header_compiler_direct	लेबल; डिफ़ॉल्ट रूप से None हेडर कंपाइलर का वैकल्पिक लेबल, जिसका इस्तेमाल डायरेक्ट क्लासपथ ऐक्शन के लिए किया जाता है. इन ऐक्शन में, एपीआई जनरेट करने वाले किसी भी एनोटेशन प्रोसेसर को शामिल नहीं किया जाता. इस टूल में एनोटेशन प्रोसेसिंग की सुविधा काम नहीं करती.
ijar	लेबल; डिफ़ॉल्ट रूप से None ijar एक्सीक्यूटेबल का लेबल.
jacocorunner	लेबल; डिफ़ॉल्ट रूप से None JacocoCoverageRunner डिप्लॉय किए गए jar का लेबल.
java_runtime	लेबल; डिफ़ॉल्ट रूप से None इस टूलचेन का इस्तेमाल करने के लिए java_runtime. यह डिफ़ॉल्ट रूप से, java_runtime के एक्ज़ीक्यूशन कॉन्फ़िगरेशन में सेट होता है.
javabuilder	लेबल; डिफ़ॉल्ट रूप से None JavaBuilder डिप्लॉय किए गए jar का लेबल.
javabuilder_data	लेबल की सूची; डिफ़ॉल्ट [] है javabuilder_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
javabuilder_jvm_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] JavaBuilder को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची.
javac_supports_multiplex_workers	बूलियन; डिफ़ॉल्ट तौर पर True अगर JavaBuilder, मल्टीप्लेक्स पर्सिस्टेंट वर्कर्स के तौर पर काम करता है, तो True. अगर नहीं करता है, तो False.
javac_supports_worker_cancellation	बूलियन; डिफ़ॉल्ट तौर पर True अगर JavaBuilder, पर्सिस्टेंट वर्कर्स को रद्द करने की सुविधा देता है, तो यह वैल्यू 'सही' होगी. अगर नहीं देता है, तो यह वैल्यू 'गलत' होगी.
javac_supports_worker_multiplex_sandboxing	बूलियन; डिफ़ॉल्ट तौर पर False अगर JavaBuilder, सैंडबॉक्सिंग की सुविधा के साथ मल्टीप्लेक्स पर्सिस्टेंट वर्कर्स के तौर पर काम करता है, तो यह वैल्यू 'सही' होगी. अगर ऐसा नहीं है, तो यह वैल्यू 'गलत' होगी.
javac_supports_workers	बूलियन; डिफ़ॉल्ट तौर पर True अगर JavaBuilder, पर्सिस्टेंट वर्कर्स के तौर पर काम करता है, तो यह वैल्यू 'सही' होगी. अगर नहीं, तो यह वैल्यू 'गलत' होगी.
javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] Java कंपाइलर के लिए अतिरिक्त आर्ग्युमेंट की सूची. Java कंपाइलर के फ़्लैग की पूरी सूची के लिए, कृपया Java कंपाइलर के दस्तावेज़ देखें.
jspecify_implicit_deps	लेबल; डिफ़ॉल्ट रूप से None एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
jspecify_javacopts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
jspecify_packages	लेबल की सूची; डिफ़ॉल्ट [] है एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
jspecify_processor	लेबल; डिफ़ॉल्ट रूप से None एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
jspecify_processor_class	स्ट्रिंग; डिफ़ॉल्ट रूप से "" एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
jspecify_stubs	लेबल की सूची; डिफ़ॉल्ट [] है एक्सपेरिमेंट के तौर पर उपलब्ध है, इसका इस्तेमाल न करें!
jvm_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] Java कंपाइलर को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची. इस विकल्प के लिए, संभावित फ़्लैग की पूरी सूची देखने के लिए, कृपया Java वर्चुअल मशीन का दस्तावेज़ देखें.
misc	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इस्तेमाल नहीं किया जा सकता: इसके बजाय javacopts का इस्तेमाल करें
oneversion	लेबल; डिफ़ॉल्ट रूप से None एनफ़ोर्समेंट के लिए इस्तेमाल होने वाले एक वर्शन वाले बाइनरी का लेबल.
oneversion_allowlist	लेबल; डिफ़ॉल्ट रूप से None एक वर्शन की अनुमति वाली सूची का लेबल.
oneversion_allowlist_for_tests	लेबल; डिफ़ॉल्ट रूप से None टेस्ट के लिए, एक वर्शन की अनुमति वाली सूची का लेबल.
oneversion_whitelist	लेबल; डिफ़ॉल्ट रूप से None अब काम नहीं करता: इसके बजाय, oneversion_allowlist का इस्तेमाल करें
package_configuration	लेबल की सूची; डिफ़ॉल्ट [] है कॉन्फ़िगरेशन, जिसे पैकेज के बताए गए ग्रुप पर लागू करना है.
proguard_allowlister	लेबल; डिफ़ॉल्ट रूप से "@bazel_tools//tools/jdk:proguard_whitelister" Proguard allowlister का लेबल.
reduced_classpath_incompatible_processors	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] इंटरनल एपीआई, इसका इस्तेमाल न करें!
singlejar	लेबल; डिफ़ॉल्ट रूप से None SingleJar डिप्लॉय jar का लेबल.
source_version	स्ट्रिंग; डिफ़ॉल्ट रूप से "" Java सोर्स का वर्शन (उदाहरण के लिए, '6' या '7'). इससे पता चलता है कि Java सोर्स कोड में कोड स्ट्रक्चर के किस सेट को इस्तेमाल करने की अनुमति है.
target_version	स्ट्रिंग; डिफ़ॉल्ट रूप से "" Java का टारगेट वर्शन (उदाहरण के लिए, '6' या '7'). इससे पता चलता है कि क्लास को किस Java रनटाइम के लिए बनाया जाना चाहिए.
timezone_data	लेबल; डिफ़ॉल्ट रूप से None टाइमज़ोन डेटा वाले रिसॉर्स जर्स का लेबल. अगर यह सेट है, तो टाइमज़ोन डेटा को सभी java_binary नियमों की रनटाइम डिपेंडेंसी के तौर पर जोड़ा जाता है.
tools	लेबल की सूची; डिफ़ॉल्ट [] है jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध टूल के लेबल.
turbine_data	लेबल की सूची; डिफ़ॉल्ट [] है turbine_jvm_opts में लेबल-एक्सपैंशन के लिए उपलब्ध डेटा के लेबल.
turbine_jvm_opts	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] turbine को कॉल करते समय, JVM के लिए आर्ग्युमेंट की सूची.
xlint	स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से [] डिफ़ॉल्ट सूची में जोड़ने या हटाने के लिए चेतावनी की सूची. इसे हटाने के लिए, इसके पहले डैश लगाएं. ज़्यादा जानकारी के लिए, -Xlint विकल्पों के बारे में Javac दस्तावेज़ देखें.