BazelCon 2022 از 16 تا 17 نوامبر به نیویورک و آنلاین می آید. امروز ثبت نام کنید!
جدید: برای روز جامعه در 15 نوامبر به ما بپیوندید! جزئیات و ثبت نام.

این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

قوانین جاوا

گزارش یک مشکل مشاهده منبع

قوانین

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)

یک بایگانی جاوا ("فایل jar")، به اضافه یک اسکریپت پوسته پوششی با همان نام قانون ایجاد می کند. اسکریپت wrapper shell از یک classpath استفاده می‌کند که شامل یک فایل jar برای هر کتابخانه است که باینری به آن بستگی دارد. هنگام اجرای اسکریپت wrapper shell، هر متغیر محیطی JAVABIN خالی بر نسخه مشخص شده از طریق پرچم --java_runtime_version Bazel اولویت دارد.

اسکریپت wrapper چندین پرچم منحصر به فرد را می پذیرد. برای فهرستی از پرچم‌های قابل تنظیم و متغیرهای محیطی پذیرفته‌شده توسط wrapper به //src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt مراجعه کنید.

اهداف خروجی ضمنی

name .jar : یک آرشیو جاوا، حاوی فایل‌های کلاس و سایر منابع مربوط به وابستگی‌های مستقیم باینری.
name -src.jar : آرشیو حاوی منابع ("مقدار منبع").
name _deploy.jar : یک بایگانی جاوا مناسب برای استقرار (فقط در صورت درخواست صریح ساخته شده است).
ساختن هدف < name >_deploy.jar برای قانون شما، یک فایل jar خود حاوی یک مانیفست ایجاد می کند که به آن اجازه می دهد با دستور java -jar یا با گزینه --singlejar اسکریپت wrapper اجرا شود. استفاده از اسکریپت wrapper به java -jar ترجیح داده می شود زیرا پرچم های JVM و گزینه های بارگیری کتابخانه های بومی را نیز پاس می کند.
Deploy jar شامل تمام کلاس هایی است که توسط یک کلاس لودر که مسیر کلاس را از اسکریپت wrapper باینری از ابتدا تا انتها جستجو می کند، پیدا می کند. همچنین شامل کتابخانه های بومی مورد نیاز برای وابستگی ها می باشد. اینها در زمان اجرا به طور خودکار در JVM بارگذاری می شوند.
اگر هدف شما یک ویژگی راه‌انداز را مشخص می‌کند، به جای اینکه یک فایل JAR معمولی باشد، _deploy.jar یک باینری بومی خواهد بود. این شامل راه‌انداز به‌علاوه وابستگی‌های بومی (C++) قانون شما است که همگی به یک باینری ثابت پیوند شده‌اند. بایت های فایل jar واقعی به آن باینری بومی اضافه می شود و یک حباب باینری منفرد حاوی کد اجرایی و جاوا ایجاد می کند. شما می توانید فایل jar به دست آمده را مستقیماً مانند هر دودویی بومی اجرا کنید.
name _deploy-src.jar : آرشیو حاوی منابع جمع آوری شده از بسته شدن گذرای هدف. اینها با کلاس‌های موجود در deploy.jar مطابقت می‌کنند، به جز مواردی که jarها هیچ منبع jar منطبقی ندارند.

ویژگی deps در یک قانون java_binary بدون srcs مجاز نیست. چنین قاعده ای به یک main_class نیاز دارد که توسط runtime_deps ارائه شده است.

قطعه کد زیر یک اشتباه رایج را نشان می دهد:

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

در عوض این کار را انجام دهید:

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

استدلال ها

ویژگی های
`name`	نام ؛ ضروری یک نام منحصر به فرد برای این هدف. استفاده از نام فایل منبع که نقطه ورود اصلی برنامه است (منهای پسوند) تمرین خوبی است. به عنوان مثال، اگر نقطه ورودی شما `Main.java` نام دارد، نام شما می تواند `Main` باشد.
`deps`	لیست برچسب ها ؛ پیش فرض `[]` لیست کتابخانه های دیگری که باید به هدف مرتبط شوند. نظرات کلی درباره `deps` را در ویژگی‌های معمولی که توسط اکثر قوانین ساخت تعریف شده‌اند، ببینید.
`srcs`	لیست برچسب ها ؛ پیش فرض `[]` فهرست فایل‌های منبعی که برای ایجاد هدف پردازش می‌شوند. این ویژگی تقریباً همیشه مورد نیاز است. استثناها را در زیر ببینید. فایل های منبع از نوع `.java` کامپایل شده اند. در مورد فایل‌های `.java` تولید شده، معمولاً توصیه می‌شود که نام قانون تولیدکننده را به جای نام خود فایل در اینجا قرار دهید. این نه تنها خوانایی را بهبود می بخشد، بلکه قانون را در برابر تغییرات آتی انعطاف پذیرتر می کند: اگر قانون تولید فایل های مختلفی در آینده ایجاد کند، فقط باید یک مکان را اصلاح کنید: `outs` قانون تولید. شما نباید قانون تولید را در `deps` فهرست کنید زیرا یک no-op است. فایل های منبع از نوع `.srcjar` باز و کامپایل می شوند. (اگر نیاز به ایجاد مجموعه ای از فایل های `.java` با ژانر دارید، این کار مفید است.) قوانین: اگر قانون (معمولا `genrule` یا `filegroup` ) هر یک از فایل های ذکر شده در بالا را ایجاد کند، به همان روشی که برای فایل های منبع توضیح داده شد استفاده می شود. این آرگومان تقریباً همیشه مورد نیاز است، مگر اینکه یک ویژگی `main_class` کلاسی را در مسیر کلاس اجرا مشخص کند یا آرگومان `runtime_deps` را مشخص کنید.
`resources`	لیست برچسب ها ؛ پیش فرض `[]` لیستی از فایل های داده ای که باید در یک جاوا گنجانده شوند. اگر منابع مشخص شده باشند، به همراه فایل‌های `.class` معمولی که توسط کامپایل تولید می‌شوند، در jar قرار می‌گیرند. محل منابع داخل فایل jar توسط ساختار پروژه تعیین می شود. Bazel ابتدا به دنبال طرح‌بندی دایرکتوری استاندارد Maven می‌گردد. اگر این مورد پیدا نشد، Bazel سپس به دنبال بالاترین دایرکتوری با نام "java" یا "javatests" می گردد (بنابراین، برای مثال، اگر منبعی در `<workspace root>/x/java/y/java/z` باشد، مسیر منبع `y/java/z` خواهد بود.این اکتشافی را نمی توان نادیده گرفت، با این حال، ویژگی `resource_strip_prefix` می تواند برای تعیین یک فهرست جایگزین خاص برای فایل های منبع استفاده شود. منابع ممکن است فایل های منبع یا فایل های تولید شده باشند.
`classpath_resources`	لیست برچسب ها ؛ پیش فرض `[]` از این گزینه استفاده نکنید مگر اینکه راه دیگری وجود نداشته باشد) فهرستی از منابعی که باید در ریشه درخت جاوا قرار گیرند. تنها هدف این ویژگی پشتیبانی از کتابخانه های شخص ثالث است که نیاز دارند منابع آنها در مسیر کلاس دقیقاً `"myconfig.xml"` پیدا شوند. به دلیل خطر تداخل فضای نام، فقط روی باینری ها مجاز است و نه کتابخانه ها.
`create_executable`	بولی؛ غیر قابل تنظیم پیش فرض `True` است منسوخ شده، به جای آن از `java_single_jar` استفاده کنید.
`deploy_env`	لیست برچسب ها ؛ پیش فرض `[]` فهرستی از دیگر اهداف `java_binary` که نشان دهنده محیط استقرار این باینری است. این ویژگی را هنگام ساخت افزونه ای که توسط `java_binary` دیگری بارگذاری می شود، تنظیم کنید. تنظیم این ویژگی، تمام وابستگی‌ها را از مسیر کلاسی زمان اجرا (و deploy jar) این باینری که بین این باینری و اهداف مشخص شده در `deploy_env` به اشتراک گذاشته شده است، حذف می‌کند.
`deploy_manifest_lines`	لیست رشته ها؛ پیش فرض `[]` فهرستی از خطوط برای افزودن به فایل `META-INF/manifest.mf` که برای هدف `_deploy.jar` ایجاد شده است. محتویات این ویژگی مشمول جایگزینی «مغیر ایجاد کنید» نیستند* .
`javacopts`	لیست رشته ها؛ پیش فرض `[]` گزینه های کامپایلر اضافی برای این کتابخانه. مشروط به جایگزینی "Make variable" و نشانه گذاری پوسته Bourne . این گزینه های کامپایلر پس از گزینه های کامپایلر جهانی به javac منتقل می شوند.
`jvm_flags`	لیست رشته ها؛ پیش فرض `[]` لیستی از پرچم‌ها برای جاسازی در اسکریپت wrapper ایجاد شده برای اجرای این باینری. مشروط به جایگزینی $(location) و "Make variable" و نشانه گذاری پوسته Bourne . اسکریپت wrapper برای یک باینری جاوا شامل یک تعریف CLASSPATH (برای یافتن تمام jar های وابسته) است و مفسر جاوا مناسب را فراخوانی می کند. خط فرمان تولید شده توسط اسکریپت wrapper شامل نام کلاس اصلی و به دنبال آن یک `"$@"` است تا بتوانید آرگومان های دیگر را بعد از نام کلاس ارسال کنید. با این حال، آرگومان های در نظر گرفته شده برای تجزیه توسط JVM باید قبل از نام کلاس در خط فرمان مشخص شوند. محتویات `jvm_flags` قبل از لیست شدن نام کلاس به اسکریپت wrapper اضافه می شود. توجه داشته باشید که این ویژگی روی خروجی های `_deploy.jar` تاثیری* ندارد.
`launcher`	برچسب ؛ پیش فرض `None` است یک باینری را مشخص کنید که برای اجرای برنامه جاوا به جای برنامه `bin/java` معمولی همراه با JDK استفاده شود. هدف باید یک `cc_binary` باشد. هر `cc_binary` که Java Invocation API را پیاده سازی می کند، می تواند به عنوان مقداری برای این ویژگی مشخص شود. به طور پیش فرض، Bazel از لانچر معمولی JDK (bin/java یا java.exe) استفاده می کند. پرچم مربوط به `--java_launcher` Bazel فقط بر آن دسته از اهداف `java_binary` و `java_test` تأثیر می گذارد که مشخصه `launcher` مشخص نکرده اند. توجه داشته باشید که وابستگی‌های بومی شما (C++، SWIG، JNI) بسته به اینکه از لانچر JDK یا راه‌انداز دیگری استفاده می‌کنید، متفاوت ساخته می‌شوند: اگر از راه‌انداز معمولی JDK (پیش‌فرض) استفاده می‌کنید، وابستگی‌های بومی به‌عنوان یک کتابخانه مشترک با نام `{name}_nativedeps.so` ساخته می‌شوند، جایی که `{name}` ویژگی `name` این قانون java_binary است. کد استفاده نشده توسط پیوند دهنده در این پیکربندی حذف نمی شود. اگر از هر راه‌انداز دیگری استفاده می‌کنید، وابستگی‌های بومی (C++) به صورت ایستا به یک باینری به نام `{name}_nativedeps` پیوند داده می‌شوند، جایی که `{name}` ویژگی `name` این قانون java_binary است. در این مورد، پیوند دهنده هر کدی را که فکر می‌کند استفاده نشده است را از باینری حاصل حذف می‌کند، به این معنی که هر کد C++ که فقط از طریق JNI به آن دسترسی پیدا می‌کند ممکن است به آن پیوند داده نشود مگر اینکه آن هدف `cc_library` `alwayslink = 1` مشخص کند. هنگام استفاده از هر راه‌اندازی غیر از راه‌انداز پیش‌فرض JDK، فرمت خروجی `*_deploy.jar` تغییر می‌کند. برای جزئیات بیشتر به اسناد اصلی java_binary مراجعه کنید.
`main_class`	رشته؛ پیش فرض `""` است نام کلاس با متد `main()` برای استفاده به عنوان نقطه ورودی. اگر یک قانون از این گزینه استفاده کند، نیازی به لیست `srcs=[...]` ندارد. بنابراین، با این ویژگی می توان یک فایل اجرایی از یک کتابخانه جاوا ایجاد کرد که از قبل حاوی یک یا چند متد `main()` است. مقدار این ویژگی یک نام کلاس است، نه یک فایل منبع. کلاس باید در زمان اجرا در دسترس باشد: ممکن است توسط این قانون کامپایل شود (از `srcs` ) یا توسط وابستگی های مستقیم یا گذرا (از طریق `runtime_deps` یا `deps` ) ارائه شود. اگر کلاس در دسترس نباشد، باینری در زمان اجرا از کار می افتد. هیچ بررسی زمان ساخت وجود ندارد.
`plugins`	لیست برچسب ها ؛ پیش فرض `[]` پلاگین های کامپایلر جاوا برای اجرا در زمان کامپایل. هر `java_plugin` مشخص شده در این ویژگی هر زمان که این قانون ساخته شود اجرا می شود. یک کتابخانه همچنین ممکن است افزونه‌هایی را از وابستگی‌هایی که از `exported_plugins` استفاده می‌کنند به ارث ببرد. منابع تولید شده توسط افزونه در jar حاصل از این قانون گنجانده می شود.
`resource_jars`	لیست برچسب ها ؛ پیش فرض `[]` منسوخ شده: به جای آن از java_import و deps یا runtime_deps استفاده کنید.
`resource_strip_prefix`	رشته؛ پیش فرض `""` است پیشوند مسیر برای حذف از منابع جاوا. اگر مشخص شده باشد، این پیشوند مسیر از هر فایلی در ویژگی `resources` حذف می شود. این یک خطا است که یک فایل منبع در این فهرست قرار ندارد. اگر مشخص نباشد (پیش‌فرض)، مسیر فایل منبع با همان منطق بسته جاوا فایل‌های منبع تعیین می‌شود. به عنوان مثال، یک فایل منبع در `stuff/java/foo/bar/a.txt` در `foo/bar/a.txt` قرار خواهد گرفت.
`runtime_deps`	لیست برچسب ها ؛ پیش فرض `[]` کتابخانه‌هایی که فقط در زمان اجرا برای باینری نهایی یا آزمایش در دسترس قرار می‌گیرند. مانند `deps` معمولی، اینها در مسیر کلاس اجرا ظاهر می‌شوند، اما بر خلاف آن‌ها، در مسیر کلاسی زمان کامپایل ظاهر نمی‌شوند. وابستگی های مورد نیاز فقط در زمان اجرا باید در اینجا فهرست شوند. ابزارهای تجزیه و تحلیل وابستگی باید اهدافی را که در `runtime_deps` و `deps` ظاهر می شوند نادیده بگیرند.
`stamp`	عدد صحیح؛ پیش فرض `-1` است اینکه اطلاعات ساخت را در باینری رمزگذاری کنیم یا نه. مقادیر ممکن: `stamp = 1` : همیشه اطلاعات ساخت را در باینری مهر کنید، حتی در ساخت های `--nostamp` . از این تنظیم باید اجتناب شود ، زیرا به طور بالقوه حافظه پنهان از راه دور را برای باینری و هر اقدام پایین دستی که به آن وابسته است از بین می برد. `stamp = 0` : همیشه اطلاعات ساخت را با مقادیر ثابت جایگزین کنید. این باعث می شود که نتایج ساخت خوبی در حافظه پنهان ذخیره شود. `stamp = -1` : جاسازی اطلاعات ساخت توسط پرچم `--[no]stamp` کنترل می شود. باینری های مهر شده بازسازی نمی شوند مگر اینکه وابستگی آنها تغییر کند.
`use_launcher`	بولی؛ پیش فرض `True` است اینکه آیا باینری باید از یک راه‌انداز سفارشی استفاده کند یا خیر. اگر این ویژگی روی false تنظیم شود، ویژگی راه‌انداز و پرچم مربوط به `--java_launcher` برای این هدف نادیده گرفته می‌شود.
`use_testrunner`	بولی؛ پیش فرض `False` است از کلاس تست runner (به طور پیش فرض `com.google.testing.junit.runner.BazelTestRunner` ) به عنوان نقطه ورودی اصلی برای یک برنامه جاوا استفاده کنید و کلاس تست را به عنوان مقدار ویژگی سیستم `bazel.test_suite` در اختیار اجراکننده آزمایش قرار دهید. می‌توانید از این برای لغو رفتار پیش‌فرض استفاده کنید، یعنی استفاده از test runner برای قوانین `java_test` ، و نه استفاده از آن برای قوانین `java_binary` . بعید است که بخواهید این کار را انجام دهید. یکی از موارد استفاده برای قوانین `AllTest` است که توسط قانون دیگری احضار می شوند (مثلاً برای راه اندازی پایگاه داده قبل از اجرای آزمایش). قانون `AllTest` باید به‌عنوان یک `java_binary` اعلان شود، اما همچنان باید از اجرای آزمایشی به عنوان نقطه ورودی اصلی خود استفاده کند. نام یک کلاس اجراکننده آزمایشی را می توان با ویژگی `main_class` رد کرد.

java_import

مشاهده منبع قانون

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

این قانون اجازه می دهد تا از فایل های jar .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`	لیست رشته ها؛ پیش فرض `[]` محدودیت های اضافی بر روی این قانون به عنوان یک کتابخانه جاوا اعمال می شود.
`exports`	لیست برچسب ها ؛ پیش فرض `[]` اهدافی که این قانون را در اختیار کاربران قرار می دهد. به java_library.exports مراجعه کنید.
`jars`	لیست برچسب ها ؛ ضروری لیست فایل های JAR ارائه شده به اهداف جاوا که به این هدف بستگی دارد.
`neverlink`	بولی؛ پیش فرض `False` است از این کتابخانه فقط برای کامپایل استفاده کنید و نه در زمان اجرا. اگر کتابخانه در حین اجرا توسط محیط زمان اجرا ارائه شود مفید است. نمونه‌هایی از کتابخانه‌هایی مانند این، APIهای IDE برای پلاگین‌های IDE یا `tools.jar` برای هر چیزی که روی یک JDK استاندارد اجرا می‌شود، هستند.
`proguard_specs`	لیست برچسب ها ؛ پیش فرض `[]` فایل هایی که به عنوان مشخصات Proguard استفاده می شوند. اینها مجموعه مشخصات مورد استفاده توسط Proguard را توصیف می کنند. در صورت مشخص شدن، بسته به این کتابخانه به هر هدف `android_binary` اضافه می شوند. فایل‌های موجود در اینجا فقط باید دارای قوانین بی‌توان، یعنی -dontnote، -dontwarn، assumenosideeffects و قوانینی باشند که با -keep شروع می‌شوند. گزینه‌های دیگر فقط می‌توانند در proguard_specs `android_binary` ظاهر شوند تا از ادغام‌های غیر توتولوژیک اطمینان حاصل شود.
`runtime_deps`	لیست برچسب ها ؛ پیش فرض `[]` کتابخانه‌هایی که فقط در زمان اجرا برای باینری نهایی یا آزمایش در دسترس قرار می‌گیرند. به java_library.runtime_deps مراجعه کنید.
`srcjar`	برچسب ؛ پیش فرض `None` است یک فایل JAR که حاوی کد منبع فایل های JAR کامپایل شده است.

java_library

مشاهده منبع قانون

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

این قانون منابع را به یک فایل .jar کامپایل و پیوند می دهد.

خروجی های ضمنی

lib name .jar : یک بایگانی جاوا حاوی فایل های کلاس.
lib name -src.jar : آرشیو حاوی منابع ("مقدار منبع").

استدلال ها

ویژگی های
`name`	نام ؛ ضروری یک نام منحصر به فرد برای این هدف.
`deps`	لیست برچسب ها ؛ پیش فرض `[]` لیست کتابخانه هایی که باید به این کتابخانه پیوند داده شوند. نظرات کلی درباره `deps` را در ویژگی‌های معمولی که توسط اکثر قوانین ساخت تعریف شده‌اند، ببینید. شیشه های ساخته شده توسط قوانین `java_library` که در `deps` فهرست شده اند در مسیر کلاسی زمان کامپایل این قانون قرار خواهند گرفت. علاوه بر این، بسته شدن موقتی `deps` ، `runtime_deps` و `exports` آنها در مسیر کلاس اجرا خواهد بود. در مقابل، اهداف در ویژگی `data` در فایل‌های اجرا گنجانده می‌شوند اما نه در مسیر کلاس زمان کامپایل و نه در زمان اجرا قرار دارند.
`srcs`	لیست برچسب ها ؛ پیش فرض `[]` فهرست فایل‌های منبعی که برای ایجاد هدف پردازش می‌شوند. این ویژگی تقریباً همیشه مورد نیاز است. استثناها را در زیر ببینید. فایل های منبع از نوع `.java` کامپایل شده اند. در مورد فایل‌های `.java` تولید شده، معمولاً توصیه می‌شود که نام قانون تولیدکننده را به جای نام خود فایل در اینجا قرار دهید. این نه تنها خوانایی را بهبود می بخشد، بلکه قانون را در برابر تغییرات آتی انعطاف پذیرتر می کند: اگر قانون تولید فایل های مختلفی در آینده ایجاد کند، فقط باید یک مکان را اصلاح کنید: `outs` قانون تولید. شما نباید قانون تولید را در `deps` فهرست کنید زیرا یک no-op است. فایل های منبع از نوع `.srcjar` باز و کامپایل می شوند. (اگر نیاز به ایجاد مجموعه ای از فایل های `.java` با ژانر دارید، این کار مفید است.) قوانین: اگر قانون (معمولا `genrule` یا `filegroup` ) هر یک از فایل های ذکر شده در بالا را ایجاد کند، به همان روشی که برای فایل های منبع توضیح داده شد استفاده می شود. فایل های منبع از نوع `.properties` به عنوان منابع در نظر گرفته می شوند. همه فایل‌های دیگر نادیده گرفته می‌شوند، تا زمانی که حداقل یک فایل از نوع فایلی که در بالا توضیح داده شد وجود داشته باشد. در غیر این صورت یک خطا مطرح می شود. این آرگومان تقریبا همیشه مورد نیاز است، مگر اینکه آرگومان `runtime_deps` را مشخص کنید.
`data`	لیست برچسب ها ؛ پیش فرض `[]` لیست فایل های مورد نیاز این کتابخانه در زمان اجرا. نظرات کلی در مورد `data` در ویژگی های معمولی که توسط اکثر قوانین ساخت تعریف شده اند، مشاهده کنید. هنگام ساختن `java_library` ، بازل این فایل ها را در جایی قرار نمی دهد. اگر فایل های `data` فایل های تولید شده باشند، Bazel آنها را تولید می کند. هنگام ساختن تستی که به این `java_library` وابسته است، Bazel فایل های `data` را به ناحیه runfiles کپی یا پیوند می دهد.
`resources`	لیست برچسب ها ؛ پیش فرض `[]` لیستی از فایل های داده ای که باید در یک جاوا گنجانده شوند. منابع ممکن است فایل های منبع یا فایل های تولید شده باشند. اگر منابع مشخص شده باشند، به همراه فایل‌های `.class` معمولی که توسط کامپایل تولید می‌شوند، در jar قرار می‌گیرند. محل منابع داخل فایل jar توسط ساختار پروژه تعیین می شود. Bazel ابتدا به دنبال طرح‌بندی دایرکتوری استاندارد Maven می‌گردد. اگر این مورد پیدا نشد، 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` است API محدود شده، استفاده نکنید!
`exported_plugins`	لیست برچسب ها ؛ پیش فرض `[]` لیست `java_plugin` ها (مثلاً پردازنده های حاشیه نویسی) برای صادرات به کتابخانه هایی که مستقیماً به این کتابخانه وابسته هستند. لیست مشخص شده `java_plugin` ها برای هر کتابخانه ای که مستقیماً به این کتابخانه وابسته است اعمال می شود، درست مثل اینکه آن کتابخانه به صراحت این برچسب ها را در `plugins` اعلام کرده باشد.
`exports`	لیست برچسب ها ؛ پیش فرض `[]` کتابخانه های صادر شده فهرست کردن قوانین در اینجا آنها را در اختیار قوانین والدین قرار می دهد، گویی که والدین صراحتاً به این قوانین وابسته هستند. این برای `deps` معمولی (غیر صادراتی) صادق نیست. خلاصه: یک قانون X می تواند به کد Y دسترسی داشته باشد اگر یک مسیر وابستگی بین آنها وجود داشته باشد که با یک لبه `deps` شروع می شود که با صفر یا بیشتر یال های `exports` شروع می شود. بیایید چند مثال برای نشان دادن این موضوع ببینیم. فرض کنید A به B بستگی دارد و B به C بستگی دارد. در این مورد C یک وابستگی گذرا از A است، بنابراین تغییر منابع C و بازسازی A همه چیز را به درستی بازسازی می کند. با این حال A نمی تواند از کلاس ها در C استفاده کند. برای اجازه دادن به آن، یا A باید C را در `deps` خود اعلام کند، یا B می تواند با اعلام C در (B) کار را برای A (و هر چیزی که ممکن است به A وابسته باشد) آسان کند. ) ویژگی `exports` . بسته شدن کتابخانه های صادر شده برای همه قوانین والدین مستقیم در دسترس است. یک مثال کمی متفاوت در نظر بگیرید: A به B بستگی دارد، B به C و D، و همچنین C را صادر می کند اما D را صادر نمی کند. اکنون A به C دسترسی دارد اما به D دسترسی ندارد. حال، اگر C و D برخی از کتابخانه ها را صادر کنند، C' و D' به ترتیب، A فقط می تواند به C' دسترسی داشته باشد اما به D' دسترسی ندارد. مهم: یک قانون صادر شده یک وابستگی منظم نیست. با چسبیدن به مثال قبلی، اگر B C را صادر می کند و می خواهد از C نیز استفاده کند، باید آن را نیز در `deps` خود فهرست کند.
`javabuilder_jvm_flags`	لیست رشته ها؛ پیش فرض `[]` API محدود شده، استفاده نکنید!
`javacopts`	لیست رشته ها؛ پیش فرض `[]` گزینه های کامپایلر اضافی برای این کتابخانه. مشروط به جایگزینی "Make variable" و نشانه گذاری پوسته Bourne . این گزینه های کامپایلر پس از گزینه های کامپایلر جهانی به javac منتقل می شوند.
`neverlink`	بولی؛ پیش فرض `False` است اینکه آیا این کتابخانه باید فقط برای کامپایل استفاده شود و نه در زمان اجرا. اگر کتابخانه در حین اجرا توسط محیط زمان اجرا ارائه شود مفید است. نمونه‌هایی از این کتابخانه‌ها عبارتند از IDE API برای پلاگین‌های IDE یا `tools.jar` برای هر چیزی که روی یک JDK استاندارد اجرا می‌شود. توجه داشته باشید که `neverlink = 1` مانع از این نمی شود که کامپایلر مطالب را از این کتابخانه به اهداف کامپایل که به آن وابسته هستند، مطابق با مشخصات زبان جاوا (به عنوان مثال، ثابت های `static final` `String` یا انواع اولیه) داخل کند. بنابراین مورد استفاده ترجیحی زمانی است که کتابخانه زمان اجرا با کتابخانه کامپایل یکسان باشد. اگر کتابخانه زمان اجرا با کتابخانه کامپایل متفاوت است، باید اطمینان حاصل کنید که فقط در جاهایی که JLS کامپایلرها را به صورت درون خطی ممنوع کرده است (و این باید برای تمام نسخه های آینده JLS برقرار باشد) متفاوت است.
`plugins`	لیست برچسب ها ؛ پیش فرض `[]` پلاگین های کامپایلر جاوا برای اجرا در زمان کامپایل. هر `java_plugin` مشخص شده در این ویژگی هر زمان که این قانون ساخته شود اجرا می شود. یک کتابخانه همچنین ممکن است افزونه‌هایی را از وابستگی‌هایی که از `exported_plugins` استفاده می‌کنند به ارث ببرد. منابع تولید شده توسط افزونه در jar حاصل از این قانون گنجانده می شود.
`proguard_specs`	لیست برچسب ها ؛ پیش فرض `[]` فایل هایی که به عنوان مشخصات Proguard استفاده می شوند. اینها مجموعه مشخصات مورد استفاده توسط Proguard را توصیف می کنند. در صورت مشخص شدن، بسته به این کتابخانه به هر هدف `android_binary` اضافه می شوند. فایل‌های موجود در اینجا فقط باید دارای قوانین بی‌توان، یعنی -dontnote، -dontwarn، assumenosideeffects و قوانینی باشند که با -keep شروع می‌شوند. گزینه‌های دیگر فقط می‌توانند در proguard_specs `android_binary` ظاهر شوند تا از ادغام‌های غیر توتولوژیک اطمینان حاصل شود.
`resource_strip_prefix`	رشته؛ پیش فرض `""` است پیشوند مسیر برای حذف از منابع جاوا. اگر مشخص شده باشد، این پیشوند مسیر از هر فایلی در ویژگی `resources` حذف می شود. این یک خطا است که یک فایل منبع در این فهرست قرار ندارد. اگر مشخص نباشد (پیش‌فرض)، مسیر فایل منبع با همان منطق بسته جاوا فایل‌های منبع تعیین می‌شود. به عنوان مثال، یک فایل منبع در `stuff/java/foo/bar/a.txt` در `foo/bar/a.txt` قرار خواهد گرفت.
`runtime_deps`	لیست برچسب ها ؛ پیش فرض `[]` کتابخانه‌هایی که فقط در زمان اجرا برای باینری نهایی یا آزمایش در دسترس قرار می‌گیرند. مانند `deps` معمولی، اینها در مسیر کلاس اجرا ظاهر می‌شوند، اما بر خلاف آن‌ها، در مسیر کلاسی زمان کامپایل ظاهر نمی‌شوند. وابستگی های مورد نیاز فقط در زمان اجرا باید در اینجا فهرست شوند. ابزارهای تجزیه و تحلیل وابستگی باید اهدافی را که در `runtime_deps` و `deps` ظاهر می شوند نادیده بگیرند.

java_lite_proto_library

مشاهده منبع قانون

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

java_lite_proto_library کد جاوا را از فایل های .proto تولید می کند.

deps باید به قوانین proto_library اشاره کند.

مثال:


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

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

proto_library(
    name = "bar",
)

استدلال ها

ویژگی های

name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

deps

لیست برچسب ها ؛ پیش فرض []

لیستی از قوانین proto_library برای تولید کد جاوا.

java_proto_library

مشاهده منبع قانون

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

java_proto_library کد جاوا را از فایل های .proto تولید می کند.

deps باید به قوانین proto_library اشاره کند.

مثال:


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

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

proto_library(
    name = "foo_proto",
)

استدلال ها

ویژگی های

name

نام ؛ ضروری

یک نام منحصر به فرد برای این هدف.

deps

لیست برچسب ها ؛ پیش فرض []

لیستی از قوانین proto_library برای تولید کد جاوا.

java_test

مشاهده منبع قانون

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

یک قانون java_test() یک تست جاوا را کامپایل می کند. تست یک بسته بندی باینری در اطراف کد تست شما است. به جای اینکه کلاس اصلی کامپایل شود، متد اصلی اجرای آزمایشی فراخوانی می شود.

اهداف خروجی ضمنی

name .jar : یک بایگانی جاوا.
name _deploy.jar : یک آرشیو جاوا مناسب برای استقرار. (فقط در صورت درخواست صریح ساخته شده است.) برای جزئیات بیشتر به شرح خروجی name _deploy.jar از java_binary مراجعه کنید.

بخش آرگومان های 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` فهرست کنید زیرا یک no-op است. فایل های منبع از نوع `.srcjar` باز و کامپایل می شوند. (اگر نیاز به ایجاد مجموعه ای از فایل های `.java` با ژانر دارید، این کار مفید است.) قوانین: اگر قانون (معمولا `genrule` یا `filegroup` ) هر یک از فایل های ذکر شده در بالا را ایجاد کند، به همان روشی که برای فایل های منبع توضیح داده شد استفاده می شود. این آرگومان تقریباً همیشه مورد نیاز است، مگر اینکه یک ویژگی `main_class` کلاسی را در مسیر کلاس اجرا مشخص کند یا آرگومان `runtime_deps` را مشخص کنید.
`data`	لیست برچسب ها ؛ پیش فرض `[]` لیست فایل های مورد نیاز این کتابخانه در زمان اجرا. نظرات کلی در مورد `data` در ویژگی های معمولی که توسط اکثر قوانین ساخت تعریف شده اند، مشاهده کنید.
`resources`	لیست برچسب ها ؛ پیش فرض `[]` لیستی از فایل های داده ای که باید در یک جاوا گنجانده شوند. منابع ممکن است فایل های منبع یا فایل های تولید شده باشند. اگر منابع مشخص شده باشند، به همراه فایل‌های `.class` معمولی که توسط کامپایل تولید می‌شوند، در jar قرار می‌گیرند. محل منابع داخل فایل jar توسط ساختار پروژه تعیین می شود. Bazel ابتدا به دنبال طرح‌بندی دایرکتوری استاندارد Maven می‌گردد. اگر این مورد پیدا نشد، 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` است API محدود شده، استفاده نکنید!
`classpath_resources`	لیست برچسب ها ؛ پیش فرض `[]` از این گزینه استفاده نکنید مگر اینکه راه دیگری وجود نداشته باشد) فهرستی از منابعی که باید در ریشه درخت جاوا قرار گیرند. تنها هدف این ویژگی پشتیبانی از کتابخانه های شخص ثالث است که نیاز دارند منابع آنها در مسیر کلاس دقیقاً `"myconfig.xml"` پیدا شوند. به دلیل خطر تداخل فضای نام، فقط روی باینری ها مجاز است و نه کتابخانه ها.
`create_executable`	بولی؛ پیش فرض `True` است منسوخ شده، به جای آن از `java_single_jar` استفاده کنید.
`deploy_manifest_lines`	لیست رشته ها؛ پیش فرض `[]` فهرستی از خطوط برای افزودن به فایل `META-INF/manifest.mf` که برای هدف `_deploy.jar` ایجاد شده است. محتویات این ویژگی مشمول جایگزینی «مغیر ایجاد کنید» نیستند* .
`javacopts`	لیست رشته ها؛ پیش فرض `[]` گزینه های کامپایلر اضافی برای این باینری. مشروط به جایگزینی "Make variable" و نشانه گذاری پوسته Bourne . این گزینه های کامپایلر پس از گزینه های کامپایلر جهانی به javac منتقل می شوند.
`jvm_flags`	لیست رشته ها؛ پیش فرض `[]` لیستی از پرچم‌ها برای جاسازی در اسکریپت wrapper ایجاد شده برای اجرای این باینری. مشروط به جایگزینی $(location) و "Make variable" و نشانه گذاری پوسته Bourne . اسکریپت wrapper برای یک باینری جاوا شامل یک تعریف CLASSPATH (برای یافتن تمام jar های وابسته) است و مفسر جاوا مناسب را فراخوانی می کند. خط فرمان تولید شده توسط اسکریپت wrapper شامل نام کلاس اصلی و به دنبال آن یک `"$@"` است تا بتوانید آرگومان های دیگر را بعد از نام کلاس ارسال کنید. با این حال، آرگومان های در نظر گرفته شده برای تجزیه توسط JVM باید قبل از نام کلاس در خط فرمان مشخص شوند. محتویات `jvm_flags` قبل از لیست شدن نام کلاس به اسکریپت wrapper اضافه می شود. توجه داشته باشید که این ویژگی روی خروجی های `_deploy.jar` تاثیری* ندارد.
`launcher`	برچسب ؛ پیش فرض `None` است یک باینری را مشخص کنید که برای اجرای برنامه جاوا به جای برنامه `bin/java` معمولی همراه با JDK استفاده شود. هدف باید یک `cc_binary` باشد. هر `cc_binary` که Java Invocation API را پیاده سازی می کند، می تواند به عنوان مقداری برای این ویژگی مشخص شود. به طور پیش فرض، Bazel از لانچر معمولی JDK (bin/java یا java.exe) استفاده می کند. پرچم مربوط به `--java_launcher` Bazel فقط بر آن دسته از اهداف `java_binary` و `java_test` تأثیر می گذارد که مشخصه `launcher` مشخص نکرده اند. توجه داشته باشید که وابستگی‌های بومی شما (C++، SWIG، JNI) بسته به اینکه از لانچر JDK یا راه‌انداز دیگری استفاده می‌کنید، متفاوت ساخته می‌شوند: اگر از راه‌انداز معمولی JDK (پیش‌فرض) استفاده می‌کنید، وابستگی‌های بومی به‌عنوان یک کتابخانه مشترک با نام `{name}_nativedeps.so` ساخته می‌شوند، جایی که `{name}` ویژگی `name` این قانون java_binary است. کد استفاده نشده توسط پیوند دهنده در این پیکربندی حذف نمی شود. اگر از هر راه‌انداز دیگری استفاده می‌کنید، وابستگی‌های بومی (C++) به صورت ایستا به یک باینری به نام `{name}_nativedeps` پیوند داده می‌شوند، جایی که `{name}` ویژگی `name` این قانون java_binary است. در این مورد، پیوند دهنده هر کدی را که فکر می‌کند استفاده نشده است را از باینری حاصل حذف می‌کند، به این معنی که هر کد C++ که فقط از طریق JNI به آن دسترسی پیدا می‌کند ممکن است به آن پیوند داده نشود مگر اینکه آن هدف `cc_library` `alwayslink = 1` مشخص کند. هنگام استفاده از هر راه‌اندازی غیر از راه‌انداز پیش‌فرض JDK، فرمت خروجی `*_deploy.jar` تغییر می‌کند. برای جزئیات بیشتر به اسناد اصلی java_binary مراجعه کنید.
`main_class`	رشته؛ پیش فرض `""` است نام کلاس با متد `main()` برای استفاده به عنوان نقطه ورودی. اگر یک قانون از این گزینه استفاده کند، نیازی به لیست `srcs=[...]` ندارد. بنابراین، با این ویژگی می توان یک فایل اجرایی از یک کتابخانه جاوا ایجاد کرد که از قبل حاوی یک یا چند متد `main()` است. مقدار این ویژگی یک نام کلاس است، نه یک فایل منبع. کلاس باید در زمان اجرا در دسترس باشد: ممکن است توسط این قانون کامپایل شود (از `srcs` ) یا توسط وابستگی های مستقیم یا گذرا (از طریق `runtime_deps` یا `deps` ) ارائه شود. اگر کلاس در دسترس نباشد، باینری در زمان اجرا از کار می افتد. هیچ بررسی زمان ساخت وجود ندارد.
`neverlink`	بولی؛ پیش فرض `False` است
`plugins`	لیست برچسب ها ؛ پیش فرض `[]` پلاگین های کامپایلر جاوا برای اجرا در زمان کامپایل. هر `java_plugin` مشخص شده در این ویژگی هر زمان که این قانون ساخته شود اجرا می شود. یک کتابخانه همچنین ممکن است افزونه‌هایی را از وابستگی‌هایی که از `exported_plugins` استفاده می‌کنند به ارث ببرد. منابع تولید شده توسط افزونه در jar حاصل از این قانون گنجانده می شود.
`resource_strip_prefix`	رشته؛ پیش فرض `""` است پیشوند مسیر برای حذف از منابع جاوا. اگر مشخص شده باشد، این پیشوند مسیر از هر فایلی در ویژگی `resources` حذف می شود. این یک خطا است که یک فایل منبع در این فهرست قرار ندارد. اگر مشخص نباشد (پیش‌فرض)، مسیر فایل منبع با همان منطق بسته جاوا فایل‌های منبع تعیین می‌شود. به عنوان مثال، یک فایل منبع در `stuff/java/foo/bar/a.txt` در `foo/bar/a.txt` قرار خواهد گرفت.
`runtime_deps`	لیست برچسب ها ؛ پیش فرض `[]` کتابخانه‌هایی که فقط در زمان اجرا برای باینری نهایی یا آزمایش در دسترس قرار می‌گیرند. مانند `deps` معمولی، اینها در مسیر کلاس اجرا ظاهر می‌شوند، اما بر خلاف آن‌ها، در مسیر کلاسی زمان کامپایل ظاهر نمی‌شوند. وابستگی های مورد نیاز فقط در زمان اجرا باید در اینجا فهرست شوند. ابزارهای تجزیه و تحلیل وابستگی باید اهدافی را که در `runtime_deps` و `deps` ظاهر می شوند نادیده بگیرند.
`stamp`	عدد صحیح؛ پیش فرض `0` است اینکه اطلاعات ساخت را در باینری رمزگذاری کنیم یا نه. مقادیر ممکن: `stamp = 1` : همیشه اطلاعات ساخت را در باینری مهر کنید، حتی در ساخت های `--nostamp` . از این تنظیم باید اجتناب شود ، زیرا به طور بالقوه حافظه پنهان از راه دور را برای باینری و هر اقدام پایین دستی که به آن وابسته است از بین می برد. `stamp = 0` : همیشه اطلاعات ساخت را با مقادیر ثابت جایگزین کنید. این باعث می شود که نتایج ساخت خوبی در حافظه پنهان ذخیره شود. `stamp = -1` : جاسازی اطلاعات ساخت توسط پرچم `--[no]stamp` کنترل می شود. باینری های مهر شده بازسازی نمی شوند مگر اینکه وابستگی آنها تغییر کند.
`test_class`	رشته؛ پیش فرض `""` است کلاس جاوا که باید توسط اجراکننده آزمایش بارگذاری شود. به طور پیش فرض، اگر این آرگومان تعریف نشده باشد، از حالت میراث استفاده می شود و به جای آن از آرگومان های تست استفاده می شود. پرچم `--nolegacy_bazel_java_test` را روی آرگومان اول تنظیم کنید. این ویژگی نام یک کلاس جاوا را که باید توسط این تست اجرا شود را مشخص می کند. به ندرت نیاز به تنظیم این وجود دارد. اگر این آرگومان حذف شود، با استفاده از `name` هدف و مسیر منبع-ریشه-نسبی آن استنباط می شود. اگر تست خارج از ریشه منبع شناخته شده قرار داشته باشد، Bazel یک خطا را گزارش می دهد اگر `test_class` تنظیم نشده باشد. برای JUnit3، کلاس تست یا باید یک زیر کلاس از `junit.framework.TestCase` باشد یا باید متد `suite()` static عمومی داشته باشد که یک `junit.framework.Test` (یا زیر کلاس `Test` ) را برمی گرداند. برای JUnit4، کلاس باید با `org.junit.runner.RunWith` حاشیه نویسی شود. این ویژگی به چندین قانون `java_test` اجازه می دهد تا یک `Test` به اشتراک بگذارند ( `TestCase` ، `TestSuite` ، ...). معمولاً اطلاعات اضافی به آن ارسال می‌شود (مثلاً از طریق `jvm_flags=['-Dkey=value']` ) به طوری که رفتار آن در هر مورد متفاوت است، مانند اجرای زیرمجموعه‌ای متفاوت از آزمایش‌ها. این ویژگی همچنین استفاده از تست های جاوا را در خارج از درخت `javatests` امکان پذیر می کند.
`use_launcher`	بولی؛ پیش فرض `True` است اینکه آیا باینری باید از یک راه‌انداز سفارشی استفاده کند یا خیر. اگر این ویژگی روی false تنظیم شود، ویژگی راه‌انداز و پرچم مربوط به `--java_launcher` برای این هدف نادیده گرفته می‌شود.
`use_testrunner`	بولی؛ پیش فرض `True` است از کلاس تست runner (به طور پیش فرض `com.google.testing.junit.runner.BazelTestRunner` ) به عنوان نقطه ورودی اصلی برای یک برنامه جاوا استفاده کنید و کلاس تست را به عنوان مقدار ویژگی سیستم `bazel.test_suite` در اختیار اجراکننده آزمایش قرار دهید. می‌توانید از این برای لغو رفتار پیش‌فرض استفاده کنید، یعنی استفاده از test runner برای قوانین `java_test` ، و نه استفاده از آن برای قوانین `java_binary` . بعید است که بخواهید این کار را انجام دهید. یکی از موارد استفاده برای قوانین `AllTest` است که توسط قانون دیگری احضار می شوند (مثلاً برای راه اندازی پایگاه داده قبل از اجرای آزمایش). قانون `AllTest` باید به‌عنوان یک `java_binary` اعلان شود، اما همچنان باید از اجرای آزمایشی به عنوان نقطه ورودی اصلی خود استفاده کند. نام یک کلاس اجراکننده آزمایشی را می توان با ویژگی `main_class` رد کرد.

java_package_configuration

مشاهده منبع قانون

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

پیکربندی برای اعمال به مجموعه ای از بسته ها. تنظیمات را می توان به java_toolchain.javacopts s اضافه کرد.

مثال:



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`	لیست رشته ها؛ پیش فرض `[]` پرچم های کامپایلر جاوا
`output_licenses`	لیست رشته ها؛ پیش فرض `[]`
`packages`	لیست برچسب ها ؛ پیش فرض `[]` مجموعه ای از `package_group` که پیکربندی باید روی آن اعمال شود.

java_plugin

مشاهده منبع قانون

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

java_plugin پلاگین هایی را برای کامپایلر جاوا که توسط Bazel اجرا می شود تعریف می کند. در حال حاضر، تنها نوع پلاگین پشتیبانی شده، پردازنده های حاشیه نویسی هستند. یک قانون java_library یا java_binary می تواند افزونه ها را بسته به آنها از طریق ویژگی plugins اجرا کند. یک java_library همچنین می‌تواند به طور خودکار افزونه‌هایی را به کتابخانه‌هایی که مستقیماً به آن وابسته هستند با استفاده از exported_plugins صادر کند.

اهداف خروجی ضمنی

libname .jar : یک بایگانی جاوا.

آرگومان ها با java_library یکسان هستند، به جز اضافه شدن آرگومان processor_class .

استدلال ها

ویژگی های
`name`	نام ؛ ضروری یک نام منحصر به فرد برای این هدف.
`deps`	لیست برچسب ها ؛ پیش فرض `[]` لیست کتابخانه هایی که باید به این کتابخانه پیوند داده شوند. نظرات کلی درباره `deps` را در ویژگی‌های معمولی که توسط اکثر قوانین ساخت تعریف شده‌اند، ببینید. شیشه های ساخته شده توسط قوانین `java_library` که در `deps` فهرست شده اند در مسیر کلاسی زمان کامپایل این قانون قرار خواهند گرفت. علاوه بر این، بسته شدن موقتی `deps` ، `runtime_deps` و `exports` آنها در مسیر کلاس اجرا خواهد بود. در مقابل، اهداف در ویژگی `data` در فایل‌های اجرا گنجانده می‌شوند اما نه در مسیر کلاس زمان کامپایل و نه در زمان اجرا قرار دارند.
`srcs`	لیست برچسب ها ؛ پیش فرض `[]` فهرست فایل‌های منبعی که برای ایجاد هدف پردازش می‌شوند. این ویژگی تقریباً همیشه مورد نیاز است. استثناها را در زیر ببینید. فایل های منبع از نوع `.java` کامپایل شده اند. در مورد فایل‌های `.java` تولید شده، معمولاً توصیه می‌شود که نام قانون تولیدکننده را به جای نام خود فایل در اینجا قرار دهید. این نه تنها خوانایی را بهبود می بخشد، بلکه قانون را در برابر تغییرات آتی انعطاف پذیرتر می کند: اگر قانون تولید فایل های مختلفی در آینده ایجاد کند، فقط باید یک مکان را اصلاح کنید: `outs` قانون تولید. شما نباید قانون تولید را در `deps` فهرست کنید زیرا یک no-op است. فایل های منبع از نوع `.srcjar` باز و کامپایل می شوند. (اگر نیاز به ایجاد مجموعه ای از فایل های `.java` با ژانر دارید، این کار مفید است.) قوانین: اگر قانون (معمولا `genrule` یا `filegroup` ) هر یک از فایل های ذکر شده در بالا را ایجاد کند، به همان روشی که برای فایل های منبع توضیح داده شد استفاده می شود. فایل های منبع از نوع `.properties` به عنوان منابع در نظر گرفته می شوند. همه فایل‌های دیگر نادیده گرفته می‌شوند، تا زمانی که حداقل یک فایل از نوع فایلی که در بالا توضیح داده شد وجود داشته باشد. در غیر این صورت یک خطا مطرح می شود. این آرگومان تقریبا همیشه مورد نیاز است، مگر اینکه آرگومان `runtime_deps` را مشخص کنید.
`data`	لیست برچسب ها ؛ پیش فرض `[]` لیست فایل های مورد نیاز این کتابخانه در زمان اجرا. نظرات کلی در مورد `data` در ویژگی های معمولی که توسط اکثر قوانین ساخت تعریف شده اند، مشاهده کنید. هنگام ساختن `java_library` ، بازل این فایل ها را در جایی قرار نمی دهد. اگر فایل های `data` فایل های تولید شده باشند، Bazel آنها را تولید می کند. هنگام ساختن تستی که به این `java_library` وابسته است، Bazel فایل های `data` را به ناحیه runfiles کپی یا پیوند می دهد.
`resources`	لیست برچسب ها ؛ پیش فرض `[]` لیستی از فایل های داده ای که باید در یک جاوا گنجانده شوند. منابع ممکن است فایل های منبع یا فایل های تولید شده باشند. اگر منابع مشخص شده باشند، به همراه فایل‌های `.class` معمولی که توسط کامپایل تولید می‌شوند، در jar قرار می‌گیرند. محل منابع داخل فایل jar توسط ساختار پروژه تعیین می شود. Bazel ابتدا به دنبال طرح‌بندی دایرکتوری استاندارد Maven می‌گردد. اگر این مورد پیدا نشد، 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` است API محدود شده، استفاده نکنید!
`generates_api`	بولی؛ پیش فرض `False` است این ویژگی، پردازشگرهای حاشیه نویسی را که کد API را تولید می کنند، علامت گذاری می کند. اگر یک قانون از یک پردازشگر حاشیه نویسی تولید کننده API استفاده کند، قوانین دیگر بسته به آن تنها در صورتی می توانند به کد تولید شده اشاره کنند که اقدامات کامپایل آنها پس از قانون تولید برنامه ریزی شده باشد. این ویژگی به Bazel دستور می دهد تا زمانی که --java_header_compilation فعال است، محدودیت های زمان بندی را معرفی کند. هشدار: این ویژگی بر عملکرد ساخت تأثیر می گذارد، فقط در صورت لزوم از آن استفاده کنید.
`javabuilder_jvm_flags`	لیست رشته ها؛ پیش فرض `[]` API محدود شده، استفاده نکنید!
`javacopts`	لیست رشته ها؛ پیش فرض `[]` گزینه های کامپایلر اضافی برای این کتابخانه. مشروط به جایگزینی "Make variable" و نشانه گذاری پوسته Bourne . این گزینه های کامپایلر پس از گزینه های کامپایلر جهانی به javac منتقل می شوند.
`neverlink`	بولی؛ پیش فرض `False` است اینکه آیا این کتابخانه باید فقط برای کامپایل استفاده شود و نه در زمان اجرا. اگر کتابخانه در حین اجرا توسط محیط زمان اجرا ارائه شود مفید است. نمونه‌هایی از این کتابخانه‌ها عبارتند از IDE API برای پلاگین‌های IDE یا `tools.jar` برای هر چیزی که روی یک JDK استاندارد اجرا می‌شود. توجه داشته باشید که `neverlink = 1` مانع از این نمی شود که کامپایلر مطالب را از این کتابخانه به اهداف کامپایل که به آن وابسته هستند، مطابق با مشخصات زبان جاوا (به عنوان مثال، ثابت های `static final` `String` یا انواع اولیه) داخل کند. بنابراین مورد استفاده ترجیحی زمانی است که کتابخانه زمان اجرا با کتابخانه کامپایل یکسان باشد. اگر کتابخانه زمان اجرا با کتابخانه کامپایل متفاوت است، باید اطمینان حاصل کنید که فقط در جاهایی که JLS کامپایلرها را به صورت درون خطی ممنوع کرده است (و این باید برای تمام نسخه های آینده JLS برقرار باشد) متفاوت است.
`output_licenses`	لیست رشته ها؛ پیش فرض `[]`
`plugins`	لیست برچسب ها ؛ پیش فرض `[]` پلاگین های کامپایلر جاوا برای اجرا در زمان کامپایل. هر `java_plugin` مشخص شده در این ویژگی هر زمان که این قانون ساخته شود اجرا می شود. یک کتابخانه همچنین ممکن است افزونه‌هایی را از وابستگی‌هایی که از `exported_plugins` استفاده می‌کنند به ارث ببرد. منابع تولید شده توسط افزونه در jar حاصل از این قانون گنجانده می شود.
`processor_class`	رشته؛ پیش فرض `""` است کلاس پردازنده، نوع کاملاً واجد شرایط کلاس است که کامپایلر جاوا باید به عنوان نقطه ورود به پردازشگر حاشیه نویسی استفاده کند. اگر مشخص نشود، این قانون یک پردازشگر حاشیه نویسی را به پردازش حاشیه نویسی کامپایلر جاوا کمک نمی کند، اما مسیر کلاس زمان اجرا آن همچنان در مسیر پردازشگر حاشیه نویسی کامپایلر گنجانده می شود. (این در درجه اول برای استفاده توسط پلاگین های Error Prone در نظر گرفته شده است که از مسیر پردازشگر حاشیه نویسی با استفاده از java.util.ServiceLoader بارگیری می شوند.)
`proguard_specs`	لیست برچسب ها ؛ پیش فرض `[]` فایل هایی که به عنوان مشخصات Proguard استفاده می شوند. اینها مجموعه مشخصات مورد استفاده توسط Proguard را توصیف می کنند. در صورت مشخص شدن، بسته به این کتابخانه به هر هدف `android_binary` اضافه می شوند. فایل‌های موجود در اینجا فقط باید دارای قوانین بی‌توان، یعنی -dontnote، -dontwarn، assumenosideeffects و قوانینی باشند که با -keep شروع می‌شوند. گزینه‌های دیگر فقط می‌توانند در proguard_specs `android_binary` ظاهر شوند تا از ادغام‌های غیر توتولوژیک اطمینان حاصل شود.
`resource_strip_prefix`	رشته؛ پیش فرض `""` است پیشوند مسیر برای حذف از منابع جاوا. اگر مشخص شده باشد، این پیشوند مسیر از هر فایلی در ویژگی `resources` حذف می شود. این یک خطا است که یک فایل منبع در این فهرست قرار ندارد. اگر مشخص نباشد (پیش‌فرض)، مسیر فایل منبع با همان منطق بسته جاوا فایل‌های منبع تعیین می‌شود. به عنوان مثال، یک فایل منبع در `stuff/java/foo/bar/a.txt` در `foo/bar/a.txt` قرار خواهد گرفت.

java_runtime

مشاهده منبع قانون

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

پیکربندی را برای زمان اجرا جاوا مشخص می کند.

مثال:



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

استدلال ها

ویژگی های
`name`	نام ؛ ضروری یک نام منحصر به فرد برای این هدف.
`srcs`	لیست برچسب ها ؛ پیش فرض `[]` تمام فایل ها در زمان اجرا
`default_cds`	برچسب ؛ پیش فرض `None` است آرشیو پیش فرض CDS برای هرمتیک `java_runtime` . هنگامی که هرمتیک برای یک هدف `java_binary` فعال است و اگر هدف با مشخص کردن ویژگی `classlist` آرشیو CDS خود را ارائه ندهد، CDS پیش‌فرض `java_runtime` در هرمتیک Deploy JAR بسته‌بندی می‌شود.
`hermetic_srcs`	لیست برچسب ها ؛ پیش فرض `[]` فایل ها در زمان اجرا مورد نیاز برای استقرار هرمتیک.
`hermetic_static_libs`	لیست برچسب ها ؛ پیش فرض `[]` کتابخانه هایی که به صورت ایستا با پرتاب کننده برای استقرار هرمتیک مرتبط هستند
`java`	برچسب ؛ پیش فرض `None` است مسیر فایل اجرایی جاوا.
`java_home`	رشته؛ پیش فرض `""` است مسیر به ریشه زمان اجرا. مشروط به جایگزینی متغیر "Make" . اگر این مسیر مطلق باشد، این قانون یک زمان اجرا غیر هرمتیک جاوا با یک مسیر شناخته شده را نشان می دهد. در آن صورت، صفات `srcs` و `java` باید خالی باشند.
`lib_ct_sym`	برچسب ؛ پیش فرض `None` است فایل lib/ct.sym برای کامپایل با `--release` مورد نیاز است. اگر مشخص نشده باشد و دقیقاً یک فایل در `srcs` وجود داشته باشد که مسیر آن به `/lib/ct.sym` ختم می شود، از آن فایل استفاده می شود.
`lib_modules`	برچسب ؛ پیش فرض `None` است فایل lib/modules مورد نیاز برای استقرار هرمتیک.
`output_licenses`	لیست رشته ها؛ پیش فرض `[]`
`version`	عدد صحیح؛ پیش فرض `0` است نسخه ویژه زمان اجرا جاوا. به عنوان مثال، عدد صحیح توسط `Runtime.version().feature()` برگردانده شده است.

java_toolchain

مشاهده منبع قانون

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

پیکربندی کامپایلر جاوا را مشخص می کند. از طریق آرگومان --java_toolchain می توان از کدام زنجیره ابزار استفاده کرد. معمولاً نباید آن نوع قوانین را بنویسید مگر اینکه بخواهید کامپایلر جاوا خود را تنظیم کنید.

مثال ها

یک مثال ساده می تواند این باشد:



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`	لیست رشته ها؛ پیش فرض `[]` لیست آرگومان های JVM هنگام فراخوانی Android Lint.
`android_lint_opts`	لیست رشته ها؛ پیش فرض `[]` لیست آرگومان های Android Lint.
`android_lint_package_configuration`	لیست برچسب ها ؛ پیش فرض `[]` پیکربندی Android Lint که باید برای گروه های بسته مشخص شده اعمال شود.
`android_lint_runner`	برچسب ؛ پیش فرض `None` است برچسب برنامه Android Lint runner، در صورت وجود.
`bootclasspath`	لیست برچسب ها ؛ پیش فرض `[]` ورودی های bootclasspath هدف جاوا. با پرچم -bootclasspath javac مطابقت دارد.
`compatible_javacopts`	خالی؛ پیش فرض `{}` است API داخلی، استفاده نکنید!
`deps_checker`	برچسب ؛ پیش فرض `None` است برچسب ImportDepsChecker Deploy jar.
`forcibly_disable_header_compilation`	بولی؛ پیش فرض `False` است --java_header_compilation را لغو می کند تا کامپایل هدر را در پلتفرم هایی که از آن پشتیبانی نمی کنند، مانند JDK 7 Bazel غیرفعال کند.
`genclass`	برچسب ؛ پیش فرض `None` است برچسب GenClass Deploy jar.
`header_compiler`	برچسب ؛ پیش فرض `None` است برچسب کامپایلر هدر. اگر --java_header_compilation فعال باشد، لازم است.
`header_compiler_builtin_processors`	لیست رشته ها؛ پیش فرض `[]` API داخلی، استفاده نکنید!
`header_compiler_direct`	برچسب ؛ پیش فرض `None` است برچسب اختیاری کامپایلر سرصفحه برای استفاده برای اقدامات مسیر کلاسی مستقیم که شامل هیچ پردازشگر حاشیه نویسی تولیدکننده API نیست. این ابزار از پردازش حاشیه نویسی پشتیبانی نمی کند.
`ijar`	برچسب ؛ پیش فرض `None` است برچسب فایل اجرایی ijar.
`jacocorunner`	برچسب ؛ پیش فرض `None` است برچسب JacocoCoverageRunner Deploy jar.
`java_runtime`	برچسب ؛ پیش فرض `None` است java_runtime برای استفاده با این زنجیره ابزار. در پیکربندی اجرا به طور پیش فرض java_runtime است.
`javabuilder`	برچسب ؛ پیش فرض `None` است برچسب جاوا بیلدر استقرار jar.
`javabuilder_data`	لیست برچسب ها ؛ پیش فرض `[]` برچسب های داده های موجود برای گسترش برچسب در javabuilder_jvm_opts.
`javabuilder_jvm_opts`	لیست رشته ها؛ پیش فرض `[]` لیست آرگومان های JVM هنگام فراخوانی JavaBuilder.
`javac_supports_multiplex_workers`	بولی؛ پیش فرض `True` است درست است اگر جاوا بیلدر از اجرای به عنوان یک کارگر دائمی چندگانه پشتیبانی می کند، اگر این کار را نمی کند نادرست است.
`javac_supports_worker_cancellation`	بولی؛ پیش فرض `True` است اگر جاوا بیلدر از لغو کارگران دائمی پشتیبانی کند درست است، اگر اینطور نباشد نادرست است.
`javac_supports_worker_multiplex_sandboxing`	بولی؛ پیش فرض `False` است درست است اگر JavaBuilder از اجرای به عنوان یک کارگر دائمی چندگانه با sandboxing پشتیبانی کند، اگر اینطور نباشد نادرست است.
`javac_supports_workers`	بولی؛ پیش فرض `True` است درست است اگر جاوا بیلدر از اجرای به‌عنوان کارگر دائمی پشتیبانی کند، اگر پشتیبانی نمی‌کند نادرست است.
`javacopts`	لیست رشته ها؛ پیش فرض `[]` لیست آرگومان های اضافی برای کامپایلر جاوا. لطفاً برای لیست گسترده پرچم‌های کامپایلر جاوا به مستندات کامپایلر جاوا مراجعه کنید.
`jspecify_implicit_deps`	برچسب ؛ پیش فرض `None` است آزمایشی، استفاده نکنید!
`jspecify_javacopts`	لیست رشته ها؛ پیش فرض `[]` آزمایشی، استفاده نکنید!
`jspecify_packages`	لیست برچسب ها ؛ پیش فرض `[]` آزمایشی، استفاده نکنید!
`jspecify_processor`	برچسب ؛ پیش فرض `None` است آزمایشی، استفاده نکنید!
`jspecify_processor_class`	رشته؛ پیش فرض `""` است آزمایشی، استفاده نکنید!
`jspecify_stubs`	لیست برچسب ها ؛ پیش فرض `[]` آزمایشی، استفاده نکنید!
`jvm_opts`	لیست رشته ها؛ پیش فرض `[]` لیست آرگومان های JVM هنگام فراخوانی کامپایلر جاوا. لطفاً برای لیست گسترده پرچم‌های احتمالی این گزینه به مستندات ماشین مجازی جاوا مراجعه کنید.
`misc`	لیست رشته ها؛ پیش فرض `[]` منسوخ شده: به جای آن از جاواکوپت استفاده کنید
`oneversion`	برچسب ؛ پیش فرض `None` است برچسب باینری اجرای یک نسخه.
`oneversion_allowlist_for_tests`	برچسب ؛ پیش فرض `None` است برچسب لیست مجاز یک نسخه برای تست ها.
`oneversion_whitelist`	برچسب ؛ پیش فرض `None` است برچسب لیست مجاز یک نسخه.
`package_configuration`	لیست برچسب ها ؛ پیش فرض `[]` پیکربندی که باید برای گروه های بسته مشخص شده اعمال شود.
`proguard_allowlister`	برچسب ؛ پیش فرض `"@bazel_tools//tools/jdk:proguard_whitelister"` است برچسب مجوز Proguard.
`reduced_classpath_incompatible_processors`	لیست رشته ها؛ پیش فرض `[]` API داخلی، استفاده نکنید!
`singlejar`	برچسب ؛ پیش فرض `None` است برچسب SingleJar Deploy jar.
`source_version`	رشته؛ پیش فرض `""` است نسخه منبع جاوا (به عنوان مثال، '6' یا '7'). مشخص می کند که کدام مجموعه از ساختارهای کد در کد منبع جاوا مجاز است.
`target_version`	رشته؛ پیش فرض `""` است نسخه هدف جاوا (به عنوان مثال، '6' یا '7'). مشخص می کند که کلاس برای کدام زمان اجرا جاوا باید ساخته شود.
`timezone_data`	برچسب ؛ پیش فرض `None` است برچسب ظرف منبع حاوی داده‌های منطقه زمانی. اگر تنظیم شود، داده‌های منطقه زمانی به‌عنوان یک وابستگی ضمنی زمان اجرا به همه قوانین java_binary اضافه می‌شوند.
`tools`	لیست برچسب ها ؛ پیش فرض `[]` برچسب‌های ابزارهای موجود برای گسترش برچسب در jvm_opts.
`turbine_data`	لیست برچسب ها ؛ پیش فرض `[]` برچسب های داده های موجود برای گسترش برچسب در turbine_jvm_opts.
`turbine_jvm_opts`	لیست رشته ها؛ پیش فرض `[]` لیست آرگومان های JVM هنگام فراخوانی توربین.
`xlint`	لیست رشته ها؛ پیش فرض `[]` لیست هشدارهایی که باید از لیست پیش فرض اضافه یا حذف شوند. قبل از آن با یک خط تیره آن را حذف می کند. لطفاً برای اطلاعات بیشتر به مستندات Javac در گزینه های -Xlint مراجعه کنید.