bazelbuild/rules_java

Java rules for Bazel

rules_java's Issues

Add support for JDK 22

JDK 22 release is available since 19th March 2024.

rules_java.5.3.5.toolchains.local_jdk/BUILD.bazel:180:10: @rules_java.5.3.5.toolchains.local_jdk//:jdk-lib: invalid label 'lib/perl5/5.32/perl/man/man3/App::Cpan.3.gz' in element 6026 of attribute 'srcs' in 'filegroup' rule: invalid target name 'lib/perl5/5.32/perl/man/man3/App::Cpan.3.gz': target names may not contain ':'

Namaste,

I'm trying to use rules_java on FreeBSD 14.0-current with bazel version 5.3.0 and see this error:

>>> bazel build ...
ERROR: /usr/home/yesudeep/.cache/bazel/_bazel_yesudeep/bfaed87c32bc05637434339d5dc30c4b/external/rules_java.5.3.5.toolchains.local_jdk/BUILD.bazel:180:10: @rules_java.5.3.5.toolchains.local_jdk//:jdk-lib: invalid label 'lib/perl5/5.32/perl/man/man3/App::Cpan.3.gz' in element 6026 of attribute 'srcs' in 'filegroup' rule: invalid target name 'lib/perl5/5.32/perl/man/man3/App::Cpan.3.gz': target names may not contain ':'
ERROR: Analysis of target '//clojurescript/toolchain:default_clojurescript_toolchain' failed; build aborted: error loading package '@rules_java.5.3.5.toolchains.local_jdk//': Package '' contains errors
INFO: Elapsed time: 0.540s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)

Would this require addressing in this repository? Not sure whether this has to do with the package or rules_java. Any help is appreciated.

Thank you.

Add support for JDK 21

JDK 21 LTS release is available since 19th September 2023.

Incompatible with latest bazel rolling release

The toolchains defined in this ruleset no longer work as of the latest bazel rolling release (6.0.0-pre.20220630.1).

With bazelisk:

$ echo "6.0.0-pre.20220630.1" > .bazelversion
$ bazel build //toolchains:toolchain_java8 
Starting local Bazel server and connecting to it...
ERROR: /Users/jsimard/src/rules_java/toolchains/BUILD:212:27: no such target '@remote_java_tools//:java_compiler_jar': target 'java_compiler_jar' not declared in package '' defined by /private/var/tmp/_bazel_jsimard/95ec1fe9f24ed3702894a39337881861/external/remote_java_tools/BUILD and referenced by '//toolchains:toolchain_java8'
ERROR: /Users/jsimard/src/rules_java/toolchains/BUILD:212:27: no such target '@remote_java_tools//:jdk_compiler_jar': target 'jdk_compiler_jar' not declared in package '' defined by /private/var/tmp/_bazel_jsimard/95ec1fe9f24ed3702894a39337881861/external/remote_java_tools/BUILD and referenced by '//toolchains:toolchain_java8'
ERROR: Analysis of target '//toolchains:toolchain_java8' failed; build aborted: Analysis failed
INFO: Elapsed time: 2.661s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (6 packages loaded, 6 targets configured)

The previous release works just fine:

$ echo "6.0.0-pre.20220608.2" > .bazelversion
$ bazel build //toolchains:toolchain_java8 
INFO: Analyzed target //toolchains:toolchain_java8 (52 packages loaded, 809 targets configured).
INFO: Found 1 target...
Target //toolchains:toolchain_java8 up-to-date (nothing to build)
INFO: Elapsed time: 9.908s, Critical Path: 0.02s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

It started failing as of this bazel commit: bazelbuild/bazel@8349a39

Which I believe is applying this change: bazelbuild/bazel@6ad6de9

If that's the case, it's my understanding that rules_java will need to stop using the java_compiler_jar and jdk_compiler_jar from remote_java_tools. Perhaps this could be done by vendoring these compiler jars in rules_java itself. I'll let maintainers decide the best way to handle this.

How to build a package for AWS Lambda ?

Hello,

I followed this: https://docs.aws.amazon.com/lambda/latest/dg/java-package.html
I'm migrating from a Gradle monorepo to Bazel and here is the last blocking step.

The code didn't changed and the packaging seems correct.

I'm actually getting a ClassNotFoundException while running my Lambda:

{
  "errorMessage": "Class not found: io.adfinitas.prometer.enrichment.handler.EnricherSpawnerHandler",
  "errorType": "java.lang.ClassNotFoundException"
}

I upload a zip from S3.

$> unzip enrichment-service.zip
Archive:  enrichment-service.zip
  inflating: lib/bin_deploy.jar

$> ls -R
enrichment-service.zip lib
./lib:
bin_deploy.jar

While investigating the deploy_bin.jar here what we got:

$> find ./lib -name '*.jar' | xargs -n1 zipinfo -1 | grep '.*.class' | sort | uniq -c | sort | grep 'io/adfinitas/prometer/enrichment/handler/EnricherSpawnerHandler'
   1 io/adfinitas/prometer/enrichment/handler/EnricherSpawnerHandler$Companion.class
   1 io/adfinitas/prometer/enrichment/handler/EnricherSpawnerHandler$handleRequest$1$invokeSuspend$$inlined$collect$1.class
   1 io/adfinitas/prometer/enrichment/handler/EnricherSpawnerHandler$handleRequest$1$invokeSuspend$$inlined$map$1$2.class
   1 io/adfinitas/prometer/enrichment/handler/EnricherSpawnerHandler$handleRequest$1$invokeSuspend$$inlined$map$1.class
   1 io/adfinitas/prometer/enrichment/handler/EnricherSpawnerHandler$handleRequest$1.class
   1 io/adfinitas/prometer/enrichment/handler/EnricherSpawnerHandler.class

I configured the class as io.adfinitas.prometer.enrichment.handler.EnricherSpawnerHandler, I even tried with ::handleRequest.

The code is in Kotlin and I so used the rules_kotlin with rules_java. I bundled my code with java_binary then with rules_pkg to get a zip file using the _deploy.jar macro.

To build my package here what I do:

load("@io_bazel_rules_kotlin//kotlin:kotlin.bzl", "kt_jvm_library", "kt_jvm_binary")

package(default_visibility = ["//visibility:public"])

kt_jvm_library(
    name = "lib",
    srcs = glob(["src/**/*.kt"]),
    deps = [
        "...",
    ]
)

load("@rules_java//java:defs.bzl", "java_binary")
java_binary(
    name = "bin",
    runtime_deps = [":lib"],
#    main_class = "io.adfinitas.prometer.enrichment.MainKt",
    create_executable = False,
)

load("@rules_pkg//:pkg.bzl", "pkg_zip")
pkg_zip(
    name = "pkg",
    package_dir = "lib",
    srcs = [
        ":bin_deploy.jar"
    ],
)

Do you have any idea about what's wrong ?

Thanks,

5.0 release lacks workspace setup (SHA): https://github.com/bazelbuild/rules_java/releases

Just staring with Bazel and can't see the SHA etc as part of the release

Dependency on `rules_license`

A dependency on rules_license may be missing from rules_java's MODULE.bazel file.

The problem is that the external/rules_java~5.5.0~toolchains~remote_java_tools/java_tools/zlib/BUILD.bazel file contains a load("@rules_license//rules:license.bzl", "license") statement which can provoque the following error.

Repro

The following command:

bazel build @@rules_java~5.5.0~toolchains~remote_java_tools//java_tools/zlib --enable_bzlmod

fails with:

No repository visible as '@rules_license' from repository '@rules_java~5.5.0~toolchains~remote_java_tools'

with an empty WORKSPACE file and the following MODULE.bazel file:

# MODULE.bazel
module(
    name = "repro",
    version = "0.1",
)

bazel_dep(name = "rules_java", version = "5.5.0")

and bazel version = 6.1.2.

Upgrade from 5.4.0 to 5.5 errors

Did something change in between these versions requiring other changes?

ERROR: .../external/bazel_tools/src/tools/launcher/BUILD:9:14: While resolving toolchains for target @bazel_tools//src/tools/launcher:launcher: invalid registered toolchain '@remotejdk19_macos_aarch64_toolchain_config_repo//:toolchain': no such package '@remotejdk19_macos_aarch64_toolchain_config_repo//': The repository '@remotejdk19_macos_aarch64_toolchain_config_repo' could not be resolved: Repository '@remotejdk19_macos_aarch64_toolchain_config_repo' is not defined

remotejdk17 toolchain selected despite explicit build flags

When using rules_java 5.4.1, I'm seeing the "wrong" toolchain selected despite setting all of:

build --java_language_version=11
build --tool_java_language_version=11
build --java_runtime_version=remotejdk_11
build --tool_java_runtime_version=remotejdk_11

Debugging the corresponding toolchain selection reveals:

$ bazel build   --toolchain_resolution_debug='@bazel_tools//tools/jdk:runtime_toolchain_type'  //kythe/java/com/google/devtools/kythe/extractors/java/standalone:javac_extractor
INFO: Build options --java_runtime_version and --tool_java_runtime_version have changed, discarding analysis cache.
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @local_jdk//:jdk; mismatching config settings: local_jdk_name_version_setting
INFO: ToolchainResolution:   Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: execution @local_config_platform//:host: Selected toolchain @remotejdk11_linux//:jdk
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_macos//:jdk; mismatching values: osx
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_macos_aarch64//:jdk; mismatching values: osx, arm64
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_win//:jdk; mismatching values: windows
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux_aarch64//:jdk; mismatching values: arm64
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux_ppc64le//:jdk; mismatching values: ppc
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux_s390x//:jdk; mismatching values: s390x
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk19_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_linux_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_linux_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_win_arm64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/cpp:toolchain_type -> toolchain @local_config_cc//:cc-compiler-k8, type @bazel_tools//tools/jdk:toolchain_type -> toolchain @rules_java//toolchains:toolchain_java11, type @bazel_tools//tools/jdk:runtime_toolchain_type -> toolchain @remotejdk11_linux//:jdk
INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/jdk:runtime_toolchain_type -> toolchain @remotejdk11_linux//:jdk
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @local_jdk//:jdk; mismatching config settings: local_jdk_name_version_setting
INFO: ToolchainResolution:   Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: execution @local_config_platform//:host: Selected toolchain @remotejdk11_linux//:jdk
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_macos//:jdk; mismatching values: osx
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_macos_aarch64//:jdk; mismatching values: osx, arm64
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_win//:jdk; mismatching values: windows
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @local_jdk//:jdk; mismatching config settings: local_jdk_name_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:   Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: execution @local_config_platform//:host: Selected toolchain @remotejdk17_linux//:jdk
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_macos//:jdk; mismatching values: osx
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_macos_aarch64//:jdk; mismatching values: osx, arm64
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk15_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_win//:jdk; mismatching values: windows
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux_ppc64le//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk16_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux_s390x//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk19_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_linux_aarch64//:jdk; mismatching values: arm64
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux_aarch64//:jdk; mismatching values: arm64
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux_ppc64le//:jdk; mismatching values: ppc
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux_s390x//:jdk; mismatching values: s390x
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk19_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk17_linux_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_linux_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_win_arm64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/jdk:runtime_toolchain_type -> toolchain @remotejdk11_linux//:jdk
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_linux//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/cpp:toolchain_type -> toolchain @local_config_cc//:cc-compiler-k8, type @bazel_tools//tools/jdk:toolchain_type -> toolchain @rules_java//toolchains:toolchain_java11, type @bazel_tools//tools/jdk:runtime_toolchain_type -> toolchain @remotejdk11_linux//:jdk
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_linux_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_macos//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_macos_aarch64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_win//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk18_win_arm64//:jdk; mismatching config settings: prefix_version_setting
INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/jdk:runtime_toolchain_type -> toolchain @remotejdk17_linux//:jdk

Which is hard for me to interpret, but at least two of the lines show @remotejdk17_linux//:jdk being selected. Notably, that dependency is absent when using cquery as described on the "toolchains" page:

$ bazel cquery 'deps(//kythe/java/com/google/devtools/kythe/extractors/java/standalone:javac_extractor, 1)' --transitions=lite | grep toolchain\ dependency
Loading:
Loading:
Loading: 0 packages loaded
INFO: Build option --toolchain_resolution_debug has changed, discarding analysis cache.
Analyzing: target //kythe/java/com/google/devtools/kythe/extractors/java/standalone:javac_extractor (0 packages loaded, 0 targets configured)
INFO: Analyzed target //kythe/java/com/google/devtools/kythe/extractors/java/standalone:javac_extractor (0 packages loaded, 13863 targets configured).
INFO: Found 1 target...
  [toolchain dependency]#@local_config_cc//:cc-compiler-k8#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 4de6af3
  [toolchain dependency]#@rules_java//toolchains:toolchain_java11#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 4de6af3
  [toolchain dependency]#@remotejdk11_linux//:jdk#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 4de6af3
  [toolchain dependency]#@rules_java//toolchains:toolchain_java11#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 4de6af3
  [toolchain dependency]#@rules_java//toolchains:toolchain_java11#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 4de6af3
  [toolchain dependency]#@rules_java//toolchains:toolchain_java11#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 4de6af3
  [toolchain dependency]#@rules_java//toolchains:toolchain_java11#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 4de6af3
  [toolchain dependency]#@rules_java//toolchains:toolchain_java11#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 4de6af3
  [toolchain dependency]#@rules_java//toolchains:toolchain_java11#(TestTrimmingTransition + ConfigFeatureFlagTaggedTrimmingTransition) -> 4de6af3

And yet, when actually building the target:

ERROR: /usr/local/google/home/shahms/src/kythe/update-java-rules/kythe/java/com/google/devtools/kythe/extractors/java/standalone/BUILD:71:13: Building kythe/java/com/google/devtools/kythe/extractors/java/standalone/libjdk9_compatibility_shims.jar (1 source file) and running annotation processors (AutoServiceProcessor) failed: (Exit 1): java failed: error executing command (from target //kythe/java/com/google/devtools/kythe/extractors/java/standalone:jdk9_compatibility_shims) external/remotejdk17_linux/bin/java '--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED' ... (remaining 17 arguments skipped)

It clearly shows remotejdk17_linux being used. Seeing as the target in question uses JDK APIs which changed after JDK11 disregarding this requirement seems suboptimal (and is a regression from the commit we were using prior: a6cb0dbe343b67c7d4f3f11a68e327acdfc71fee1e17affa4e605129fc56bb15)

Broken local Java version detection

The current local Java version detection in _detect_java_version may return None, which in turn breaks further processing in _local_java_repository_impl.

I encountered this problem due to a broken local Java installation, which was not able to execute java -XshowSettings:properties to begin with.

Error message:

ERROR: <builtin>: fetching _local_java_repository_rule rule //:rules_java~7.3.2~toolchains~local_jdk: Traceback (most recent call last):
    File "/private/var/tmp/_bazel_administrator/02bc2c2b51523be4b85c9cb7f6299f33/external/rules_java~7.3.2/toolchains/local_java_repository.bzl", line 217, column 72, in _local_java_repository_impl
        build_file = build_file.format(RUNTIME_VERSION = version if version.isdigit() else "0")
Error: 'NoneType' value has no field or method 'isdigit'

Release: rules_java 7.3.1

Link to relevant issue and/or commit:

bazelbuild/bazel#20308
bazelbuild/bazel#20298
bazelbuild/bazel@a2207a4

cc @bazelbuild/triage

Release: rules_java 7.4.0 on BCR

I would like to use the rules_java 7.4.0 release from yesterday,

in order to remove an ugly workaround (--nojava_header_compilation) in my project (see bazelbuild/bazel#21119),

but it looks like that v7.4.0 hasn't quite made it to BCR just yet? As of writing this I am getting this error:

ERROR: Error computing the main repository mapping: in module dependency chain <root> -> [email protected]: module not found in registries: [email protected]

and indeed it's not on https://registry.bazel.build/modules/rules_java, yet.

Would it be possible to do the needful to have it appear there some time? Thanks!

cc @bazelbuild/triage

Turbine native image broke NONPREBUILT_TOOLCHAIN_CONFIGURATION

I believe d5b3ecf broke the NONPREBUILT_TOOLCHAIN_CONFIGURATION. I think the fix is to add the following line to the NONPREBUILT_TOOLCHAIN_CONFIGURATION dict, but I am not sure.

header_compiler_direct = [Label("@remote_java_tools//:TurbineDirect")],

Please add shim for java_common

Description of the problem / feature request:

native.java_common is a big chunk of Java rules logic embedded into Bazel, and required by rulesets that do complex Java compilation of their own ("JVM sandwich").

To simplify the migration to Starlark-only Java support, please add a wrapper in this repository that is API-compatible with java_common.

[FreeBSD] No matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type

I'm not sure but how would one add toolchains for FreeBSD?

This is what I see when using Bazel 6.0.0 on FreeBSD 14-CURRENT amd64:

Sun Jan 01 10:13 PM yesudeep at foo running bash5.2 on FreeBSD 14.0-CURRENT amd64
in ~/code/rules_clojure   main
>>> bazel build ...
ERROR: /usr/home/yesudeep/.cache/bazel/_bazel_yesudeep/bfaed87c32bc05637434339d5dc30c4b/external/bazel_tools~remote_coverage_tools_extension~remote_coverage_tools/BUILD:10:12: While resolving toolchains for target @bazel_tools~remote_coverage_tools_extension~remote_coverage_tools//:Main: No matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type.
To debug, rerun with --toolchain_resolution_debug='@bazel_tools//tools/jdk:runtime_toolchain_type'
If platforms or toolchains are a new concept for you, we'd encourage reading https://bazel.build/concepts/platforms-intro.
ERROR: Analysis of target '//tests/hello_world:core_clojure_test' failed; build aborted:
INFO: Elapsed time: 0.203s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)

Thank you! :)

How to use `remote_java_repository` with a JDK release where Java home is nested?

I'm trying to use remote_java_repository with GraalVM releases on MacOS.

When extracting the package the layout is of the form:

└── Contents
    ├── Home
    │   ├── bin
    │   │   ├── java
    │   │   ├── javac

There are no top level symlinks into the nested bin directory as can be seen in the Zulu JDK releases that remote_java_repository is normally used with.

Would it be possible to make this rule configurable so that the path to the Java home inside the extracted distribution can be customized?

README.md lacks basic usage and clarity about built-in java support vs. what's provided by rules_java

I'm not clear on how users are supposed to use rules_java vs. the java rules that seem to come built into Bazel. The README.md could clarify this.

The special treatment is mentioned here, but I don't follow what's going on exactly bazelbuild/bazel#14370:

rules_java is still an external repository and it is imported by default via workspace prefix mechanism. The version of rules_java that is imported has not changed since 2019-07-03.

There is a "builtin" java_library implementation. But this does not change how rules_java are imported. So if you are loading a different version of rules_java in your WORKSPACE you should continue to do so.

What is the "workspace prefix mechanism?" How can I update or see what verison of rules_java are being imported implicitly? Why are such rules available using @bazel_tools rather than @rules_java?

java_tools should have prebuilt Linux AArch64 binaries

Currently, only four platforms have prebuilt java_tools binaries (singlejar, ijar, etc.): linux, windows, darwin_x86_64, darwin_arm64.

rules_java/java/repositories.bzl

Lines 27 to 51 in 3c34c81

	"java_tools_linux": {
	"mirror_url": "https://mirror.bazel.build/bazel_java_tools/releases/java/v13.4/java_tools_linux-v13.4.zip",
	"github_url": "https://github.com/bazelbuild/java_tools/releases/download/java_v13.4/java_tools_linux-v13.4.zip",
	"sha": "ba10f09a138cf185d04cbc807d67a3da42ab13d618c5d1ce20d776e199c33a39",
	},
	"java_tools_windows": {
	"mirror_url": "https://mirror.bazel.build/bazel_java_tools/releases/java/v13.4/java_tools_windows-v13.4.zip",
	"github_url": "https://github.com/bazelbuild/java_tools/releases/download/java_v13.4/java_tools_windows-v13.4.zip",
	"sha": "fe2f88169696d6c6fc6e90ba61bb46be7d0ae3693cbafdf336041bf56679e8d1",
	},
	"java_tools_darwin_x86_64": {
	"mirror_url": "https://mirror.bazel.build/bazel_java_tools/releases/java/v13.4/java_tools_darwin_x86_64-v13.4.zip",
	"github_url": "https://github.com/bazelbuild/java_tools/releases/download/java_v13.4/java_tools_darwin_x86_64-v13.4.zip",
	"sha": "4523aec4d09c587091a2dae6f5c9bc6922c220f3b6030e5aba9c8f015913cc65",
	},
	"java_tools_darwin_arm64": {
	"mirror_url": "https://mirror.bazel.build/bazel_java_tools/releases/java/v13.4/java_tools_darwin_arm64-v13.4.zip",
	"github_url": "https://github.com/bazelbuild/java_tools/releases/download/java_v13.4/java_tools_darwin_arm64-v13.4.zip",
	"sha": "076a7e198ad077f8c7d997986ef5102427fae6bbfce7a7852d2e080ed8767528",
	},
	"java_tools": {
	"mirror_url": "https://mirror.bazel.build/bazel_java_tools/releases/java/v13.4/java_tools-v13.4.zip",
	"github_url": "https://github.com/bazelbuild/java_tools/releases/download/java_v13.4/java_tools-v13.4.zip",
	"sha": "e025fd260ac39b47c111f5212d64ec0d00d85dec16e49368aae82fc626a940cf",
	},

However, other parts of rules_java supports more platforms, like remotejdk21 which additionally supports Linux AArch64. It would be great if rules_java can distribute prebuilt Linux AArch64 binaries for java_tools, bringing it inline with JDK.

Add Java 14 Support

It would be great if there was support for Java 14

Prior art for supporting Java 12: bazelbuild/java_tools#9

Problem in version 6.5.0: no such target '@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type'

When upgrading from 6.4.0 to 6.5.0 I noticed this failure:

ERROR: <snip>/external/remotejdk11_linux_toolchain_config_repo/BUILD.bazel:27:10: no such target 
'@bazel_tools//tools/jdk:bootstrap_runtime_toolchain_type': 
target 'bootstrap_runtime_toolchain_type' not declared in package 'tools/jdk' defined by 
<snip>/external/bazel_tools/tools/jdk/BUILD (Tip: use `query "@bazel_tools//tools/jdk:*"` to see all the targets in that package) 
and referenced by '@remotejdk11_linux_toolchain_config_repo//:bootstrap_runtime_toolchain'

ERROR: <snip>/external/bazel_tools/src/tools/launcher/BUILD:9:14: While resolving toolchains for target @bazel_tools//src/tools/launcher:launcher: 
invalid registered toolchain '@remotejdk11_linux_toolchain_config_repo//:bootstrap_runtime_toolchain': 
Analysis failed

Push a new release containing latest JDK versions

Could we push a new release of rules_java that contains 36a7611? Then we could push the new version to BCR, which fixes a bug in Bazel when building with Bzlmod enabled (bazelbuild/bazel#16109).

We should probably first decide what the next version number should be, since the MODULE.bazel file needs to be updated too.

Using default_java_toolchain, etc from //toolchains as opposed to @bazel_tools doesn't work

get errors like

ERROR: /Users/geoff/code/mms/server/BUILD.bazel:592:23: no such package 'toolchains': BUILD file not found in any of the following directories. Add a BUILD file to a directory to mark it as a package.
 - /Users/geoff/code/mms/toolchains and referenced by '//server:java_toolchain_config'
ERROR: /Users/geoff/code/mms/server/BUILD.bazel:592:23: no such package 'toolchains': BUILD file not found in any of the following directories. Add a BUILD file to a directory to mark it as a package.
 - /Users/geoff/code/mms/toolchains and referenced by '//server:java_toolchain_config'
ERROR: /Users/geoff/code/mms/server/BUILD.bazel:592:23: no such package 'toolchains': BUILD file not found in any of the following directories. Add a BUILD file to a directory to mark it as a package.
 - /Users/geoff/code/mms/toolchains and referenced by '//server:java_toolchain_config'
ERROR: /Users/geoff/code/mms/server/BUILD.bazel:592:23: no such package 'toolchains': BUILD file not found in any of the following directories. Add a BUILD file to a directory to mark it as a package.
 - /Users/geoff/code/mms/toolchains and referenced by '//server:java_toolchain_config'

I assume it's because all the labels in default_java_toolchain.bzl like "//toolchains:singlejar" need to be wrapped in Label() or something so that they're relative to @rules_java?

Provide a way of packaging separate layers into Java container after deprecation of rules_docker

(It feels awkward to ask this question here, but it is a follow-up of this suggestion over at rules_oci )

As the maintainers have decided that the rules_oci repository should remain language agnostic, it is quite unclear where to go with questions for language-specific containers, so following @alexeagle 's advice I am trying over here.

I would like to migrate from rules_docker to rules_oci, but the functionality to package depsets into separate layers has not been provided by the new rules (_jar_app_layer_impl ).

Would it be possible to provide similar functionality in a .defs file in this repository, and could someone help me out in porting it?

CI postsubmit is broken

See postsubmit run here: https://buildkite.com/bazel/google-rules-java-presubmit/builds/236#018c7dea-6306-4705-8094-d2ee66c8c48f

Error message:

(17:13:37) ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/ec321eb2cc2d0f8f91b676b6d4c66c29/external/rules_pkg~0.9.1/pkg/releasing/BUILD:42:10: While resolving toolchains for target @@rules_pkg~0.9.1//pkg/releasing:print_rel_notes (5a74646): No matching toolchains found for types @@bazel_tools//tools/python:toolchain_type.
To debug, rerun with --toolchain_resolution_debug='@@bazel_tools//tools/python:toolchain_type'
If platforms or toolchains are a new concept for you, we'd encourage reading https://bazel.build/concepts/platforms-intro.

unnecessary stubbings errors are swallowed when tests run with Mockito

The following two issues are found when I have unnecessary stubbing in test with Mockito.

1. unnecessary stubbings errors are swallowed and test passed when test_filter is being used, however, it failed as expected without test_filter
2. unnecessary stubbings errors are NOT reported in JUnit reports regardless of using test_filter or not. The JUnit report shows all tests have passed.

Please follow this repo to reproduce the issue locally.

Question: How to override the remote JDK version

Hi, I'm using remote JDK 11 https://github.com/bazelbuild/rules_java/blob/master/java/repositories.bzl#L154 which currently pulls version 11.0.12. Azul has released a newer version, 11.0.14, which I would like to use.

I'm trying to add this in my project:

    remote_java_repository(
        name = "remotejdk11_macos",
        exec_compatible_with = [
            "@platforms//os:macos",
            "@platforms//cpu:x86_64",
        ],
        sha256 = "fbfe3da2024a170b77efd94946aeb95ffe54377134403f92c682376e1f06e8f5",
        strip_prefix = "zulu11.54.25-ca-jdk11.0.14.1-macosx_x64",
        urls = [
            "https://jfrog.booking.com/artifactory/zulu-remote/zulu11.54.25-ca-jdk11.0.14.1-macosx_x64.tar.gz",
            "https://cdn.azul.com/zulu-embedded/bin/zulu11.54.25-ca-jdk11.0.14.1-macosx_x64.tar.gz",
        ],
        version = "11",
    )

But I still get 11.0.12

How can I override the version provided out of the box?

Where's the documentation? How do I force to use the local JVM?

Hi,

Before anyone asks, I'm using Bazel 7.0.0 with rules_java 7.4.0 and java_tools 13.4.

I wanted to know how do I force this library to use only the local JVM, because the build system I have has a strict "one version of every tool" policy. One Python, one Golang, one GCC, one NodeJS, one Scala, one Java, etc.

The reason why I wanted this, is because the codebase I tend to is not ready to be compiled with Java 21, which rules_java 7.4.0 seems to be using for literally everything.

So I wanted to read the documentation. Finding out there is none, I started reading the code - comments may lie, but code never lies. I'm having a really hard time understanding how the compile warnings we get only in Java 21 manage to bleed into Java 17 and 11 once I patch this line to reflect our wishes - https://github.com/bazelbuild/rules_java/blob/7.4.0/toolchains/default_java_toolchain.bzl#L95

Warnings during Java compilation are treated as errors. Please don't ask me why.

Also the reason why I expected to find the documentation in this repository is because almost every Bazel rules does this. rules_java is one of the exceptions and outliers to this unwritten trend. The majority of Bazel rules have this kind of documentation and therefore set up some kind of expectation in the end users, I'm afraid.

There's a million options in Bazel to change the Java version and none of them seem to work. They are no-ops at best. At worst, they are deprecated so badly that merely having them in .bazelrc will make Bazel refuse to get up. This is a separate problem and I hope to address this in a separate issue if I'm still bothered enough to care about it.

I'm now writing this issue and I'm like "someone will be like ohhhhhhh did you use the search function? we have the docs here, there's always someone like that". OK I tried these links:

• https://bazel.build/reference/be/java?hl=pl it's just a page that says "8024249765089568664" - wtf?
• https://bazel.build/reference/be/java#java_toolchain there's no "use local JVM and ignore all the remote garbage" function/switch/variable
• https://github.com/bazelbuild/rules_java/blob/7.4.0/toolchains/default_java_toolchain.bzl#L95 and https://github.com/bazelbuild/rules_java/blob/7.4.0/java/repositories.bzl were filling in for documentation due to lack thereof and I honestly fail to understand how we get from calling @rules_java//java/repositories.bzl:rules_java_dependencies() and then @rules_java//java/repositories.bzl:rules_java_toolchains() to getting rekt by an updooter hardcode in @rules_java//toolchains/default_java_toolchain.bzl:default_java_toolchain()

Can someone who is more knowledgeable in these matters please tell me how can I solve this issue? How can I tell rules_java and Bazel and everything in the goddamn monorepo that I want to use a local JVM?

Please document copyright holders

Please add an AUTHORS file or similar that documents who holds the copyright for this project.

rules_java not respecting --tool_java_language_version/--tool_java_runtime_version for test_jar's as of at least 7.1.0

When upgrading to Bazel 7.0.0, which upgraded my version of rules_java to 7.1.0, I have found that when building a test jar it has upgraded to using Java 21 despite passing the following in my .bazelrc file:

build --java_language_version=11
build --java_runtime_version=remotejdk_11
build --tool_java_language_version=11
build --tool_java_runtime_version=remotejdk_11

When building I can see that Java 21 is being used to compile the test jar in the error output with the path to java being external/remotejdk21_macos_aarch64/bin/java. I would expect this path to be a Java 11 JDK with the above options in the .bazelrc.

I have also tried upgrading to rules_java 7.3.2 and that also fails with the same issue.

Question: How to find a JDK runtime with `master`?

I've been using rules_java 5.0.0 successfully, but I'll soon need to update to include recent changes in master to support the latest bazel 6.x rolling releases.

Prior to 338c418 the JDK runtime toolchain was being found correctly, but after that commit I get the following error:

ERROR: /.../BUILD:21:19: While resolving toolchains for target //{my-target}: no matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type

Here's the complete error

INFO: Repository remotejdk11_macos_aarch64 instantiated at:
  /Users/jsimard/src/envoy-mobile/WORKSPACE:58:26: in <toplevel>
  /private/var/tmp/_bazel_jsimard/7140f038a5c13b01a171c93151a000da/external/envoy_mobile/bazel/envoy_mobile_dependencies.bzl:53:24: in envoy_mobile_dependencies
  /private/var/tmp/_bazel_jsimard/7140f038a5c13b01a171c93151a000da/external/envoy_mobile/bazel/envoy_mobile_dependencies.bzl:62:28: in kotlin_dependencies
  /private/var/tmp/_bazel_jsimard/7140f038a5c13b01a171c93151a000da/external/rules_java/java/repositories.bzl:469:23: in rules_java_dependencies
  /private/var/tmp/_bazel_jsimard/7140f038a5c13b01a171c93151a000da/external/rules_java/java/repositories.bzl:233:10: in remote_jdk11_repos
  /private/var/tmp/_bazel_jsimard/7140f038a5c13b01a171c93151a000da/external/bazel_tools/tools/build_defs/repo/utils.bzl:233:18: in maybe
  /private/var/tmp/_bazel_jsimard/7140f038a5c13b01a171c93151a000da/external/rules_java/toolchains/remote_java_repository.bzl:48:17: in remote_java_repository
Repository rule http_archive defined at:
  /private/var/tmp/_bazel_jsimard/7140f038a5c13b01a171c93151a000da/external/bazel_tools/tools/build_defs/repo/http.bzl:353:31: in <toplevel>
ERROR: /Users/jsimard/src/envoy-mobile/library/kotlin/io/envoyproxy/envoymobile/BUILD:21:19: While resolving toolchains for target //library/kotlin/io/envoyproxy/envoymobile:envoy_lib_kt: no matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type

I'm probably not specifying something I should be, or perhaps this is considered a bug? I'm not sure, so I'm phrasing this as a question.

To reproduce you can clone Envoy Mobile and run the following command:

./bazelw build android_dist --config=android --override_repository=rules_java=/path/to/rules_java

I'll work to reduce and simplify the repro case but I wanted to share now in case the solution was obvious to more experienced users or maintainers of rules_java.

Thanks!

JRE logs to stdout and breaks javac/scalac worker on certain environments

ERROR: <redacted>/BUILD:3:14: scala @//<redacted> failed: Worker process returned an unparseable WorkResponse!
Did you try to print something to stdout? Workers aren't allowed to do this, as it breaks the protocol between Bazel and the worker process.
---8<---8<--- Start of response ---8<---8<---
[0.000s][warning][os,container] Duplicate cpuset controllers detected. Picking /sys/fs/cgroup/cpuset, skipping /run/lxcfs/controllers/cpuset.
---8<---8<--- End of response ---8<---8<---
---8<---8<--- Exception details ---8<---8<---
com.google.protobuf.InvalidProtocolBufferException$InvalidWireTypeException: Protocol message tag had invalid wire type.
	at com.google.protobuf.InvalidProtocolBufferException.invalidWireType(InvalidProtocolBufferException.java:134)
	at com.google.protobuf.UnknownFieldSet$Builder.mergeFieldFrom(UnknownFieldSet.java:527)
	at com.google.protobuf.GeneratedMessageV3$Builder.parseUnknownField(GeneratedMessageV3.java:863)
	at com.google.devtools.build.lib.worker.WorkerProtocol$WorkResponse$Builder.mergeFrom(WorkerProtocol.java:3037)
	at com.google.devtools.build.lib.worker.WorkerProtocol$WorkResponse$1.parsePartialFrom(WorkerProtocol.java:3333)
	at com.google.devtools.build.lib.worker.WorkerProtocol$WorkResponse$1.parsePartialFrom(WorkerProtocol.java:3325)
	at com.google.protobuf.AbstractParser.parsePartialFrom(AbstractParser.java:215)
	at com.google.protobuf.AbstractParser.parsePartialDelimitedFrom(AbstractParser.java:255)
	at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:267)
	at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:272)
	at com.google.devtools.build.lib.worker.WorkerProtocol$WorkResponse$1.parseDelimitedFrom(WorkerProtocol.java:3325)
	at com.google.protobuf.GeneratedMessageV3.parseDelimitedWithIOException(GeneratedMessageV3.java:382)
	at com.google.devtools.build.lib.worker.WorkerProtocol$WorkResponse.parseDelimitedFrom(WorkerProtocol.java:2810)
	at com.google.devtools.build.lib.worker.ProtoWorkerProtocol.getResponse(ProtoWorkerProtocol.java:46)
	at com.google.devtools.build.lib.worker.SingleplexWorker.getResponse(SingleplexWorker.java:141)
	at com.google.devtools.build.lib.worker.WorkerSpawnRunner.executeRequest(WorkerSpawnRunner.java:715)
	at com.google.devtools.build.lib.worker.WorkerSpawnRunner.execInWorkerClassic(WorkerSpawnRunner.java:575)
	at com.google.devtools.build.lib.worker.WorkerSpawnRunner.execInWorker(WorkerSpawnRunner.java:359)
	at com.google.devtools.build.lib.worker.WorkerSpawnRunner.exec(WorkerSpawnRunner.java:205)
	at com.google.devtools.build.lib.exec.SpawnRunner.execAsync(SpawnRunner.java:301)
	at com.google.devtools.build.lib.exec.AbstractSpawnStrategy.exec(AbstractSpawnStrategy.java:152)
	at com.google.devtools.build.lib.exec.AbstractSpawnStrategy.exec(AbstractSpawnStrategy.java:112)
	at com.google.devtools.build.lib.actions.SpawnStrategy.beginExecution(SpawnStrategy.java:47)
	at com.google.devtools.build.lib.exec.SpawnStrategyResolver.beginExecution(SpawnStrategyResolver.java:64)
	at com.google.devtools.build.lib.analysis.actions.SpawnAction.beginExecution(SpawnAction.java:353)
	at com.google.devtools.build.lib.actions.Action.execute(Action.java:133)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$5.execute(SkyframeActionExecutor.java:961)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$ActionRunner.continueAction(SkyframeActionExecutor.java:1128)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$ActionRunner.run(SkyframeActionExecutor.java:1086)
	at com.google.devtools.build.lib.skyframe.ActionExecutionState.runStateMachine(ActionExecutionState.java:160)
	at com.google.devtools.build.lib.skyframe.ActionExecutionState.getResultOrDependOnFuture(ActionExecutionState.java:93)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor.executeAction(SkyframeActionExecutor.java:519)
	at com.google.devtools.build.lib.skyframe.ActionExecutionFunction.checkCacheAndExecuteIfNeeded(ActionExecutionFunction.java:827)
	at com.google.devtools.build.lib.skyframe.ActionExecutionFunction.computeInternal(ActionExecutionFunction.java:323)
	at com.google.devtools.build.lib.skyframe.ActionExecutionFunction.compute(ActionExecutionFunction.java:161)
	at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:562)
	at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:365)
	at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
---8<---8<--- End of exception details ---8<---8<---
---8<---8<--- Start of log, file at <redacted>/f9e66bea7ff8f376038e2deb81cb83c9/bazel-workers/worker-4-Scalac.log ---8<---8<---
(empty)
---8<---8<--- End of log ---8<---8<---

It turned out that recent version of jre logs to stdout (JDK-8272121, JDK-8153723), and may break java bazel woker should any warning logged. It would be nice if we include jvm flags in the toolchain config, so that the jre logs to stderr instead.

Add rules_java to mirror.bazel.build

Similar to bazelbuild/rules_python#400, would it be possible to have rules_java release in the bazel mirror?

@philwo could it be possible? Should someone responsible of the repository agree?

Request: Link to documentation in README

Can someone please add a link to the java rules documentation to the top level README.md?

https://docs.bazel.build/versions/master/be/java.html

Improve performance when running a large number of JUnit tests

Title is a bit vague here, apologies for that.

Out-of-the-box, it is only possible to provide a single entry point to java_test, e.g.

java_test(
    name = "com.example.MyLovelyUnitTest",
    test_class =  "com.example.MyLovelyUnitTest",
    srcs = [ ... ],
    # etc etc
)

If one wishes to make a target from multiple classes, there are currently two well publicised workarounds:

1. Use a macro wrapper;
2. Use a @Suite or similar.

Unfortunately, each of these comes with a negative side effect wrt. performance:

1. Using a macro wrapper to turn the glob of source files into distinct java_test targets is documented to have a significant performance impact due to having to create and tear-down workers. To give a rough idea of the impact of this, here are some numbers taken from a Bazel project with ~5000 unit tests using a @Suite:

$ bazel clean
$ time bazel test //... --build_tests_only --test_lang_filters=java --test_size_filters=small
...
Executed 498 out of 498 tests: 498 tests pass.
...
bazel test //... --build_tests_only --test_lang_filters=java   2.58s user 1.55s system 0% cpu 16:41.63 total

... vs using a macro wrapper + aggregate test_suite:

$ bazel clean
$ time bazel test //... --build_tests_only --test_lang_filters=java  --test_size_filters=small
...
Executed 4691 out of 4691 tests: 4691 tests pass.
...
./bb bazel bz test //... --build_tests_only --test_lang_filters=java   2.72s user 1.69s system 0% cpu 26:47.95 total

Both of these runs were operating over the same set of tests, but using a separate java_test for each individual class causes the build time to increase by ~60%.

2. Generating a @Suite (either at compile time or dynamically via something like AllTests) clashes with --flaky_test_attempts as, if any test case fails, the entire suite is detected as having failed and so all tests are run again. This can be somewhat mitigated by sharding but there's a cap of 50 on the number of shards.

Option 1 is "okay" in cases where there are few, long-running tests; option 2 is "okay" for a lot of fast running tests. It would be nice to have a "one-size-fits-all" solution.

There has been an open issue in the main Bazel repository for a few years now that has a bit of overlap, but that one seems a bit more focused around convenience rather than performance. As the Java rules are being broken out, I thought it might make sense to move it over here for an updated discussion.

When I came across the original issue, I did a very quick-and-hacky PoC of how the built-in Bazel test runner could be updated to support multiple classes; however, on revisiting this I'm not sure if that would actually solve the performance problem on its own, as it looks as though the flaky test attempts is handled outside the test runner process, and so I'm guessing this solution would end up just working in the same way as a @Suite.

Building simple java proto fails with ERROR: ERROR: error loading package '': cannot load '@rules_java//java:repositories.bzl': no such file

I am creating a simple hello world project that uses protobuf and it fails on the first stage of building java protos.

Added to WORKSPACE as described here:

http_archive(
    name = "rules_java",
    url = "https://github.com/bazelbuild/rules_java/releases/download/4.0.0/rules_java-4.0.0.tar.gz",
    sha256 = "34b41ec683e67253043ab1a3d1e8b7c61e4e8edefbcad485381328c934d072fe",
)
load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains")
rules_java_dependencies()
rules_java_toolchains()

Here is the failure:

$ bazel build //proto::person_java_proto
ERROR: error loading package '': cannot load '@rules_java//java:repositories.bzl': no such file
INFO: Elapsed time: 0.219s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)

Can anybody give me a hand please?

java_proto_library build broken by No matching toolchains found for types @bazel_tools//tools/python:toolchain_type.

LCNC02GG727MD6R:allinone-via-bazelmod shaoxixu$ bazel build --enable_bzlmod ...
ERROR: /private/var/tmp/_bazel_shaoxixu/4d55580d1e210b29889ae47b4f95eda7/external/bazel_tools/tools/jdk/BUILD:393:10: While resolving toolchains for target @bazel_tools//tools/jdk:proguard_whitelister: No matching toolchains found for types @bazel_tools//tools/python:toolchain_type.
To debug, rerun with --toolchain_resolution_debug='@bazel_tools//tools/python:toolchain_type'
If platforms or toolchains are a new concept for you, we'd encourage reading https://bazel.build/concepts/platforms-intro.
ERROR: Analysis of target '//grpc_ecosystem/protobuf/support:pagination_java_proto' failed; build aborted:
INFO: Elapsed time: 11.887s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (117 packages loaded, 10899 targets configured)
currently loading: @protobuf~21.7//java/core
Fetching https://bcr.bazel.build/bazel_registry.json

Release: rules_java 7.3.2

As part of bazelbuild/bazel#14127, I need to update Bazel to a version of rules_java that includes d43c5d0.

Can we cut a new rules_java 7.3.2 at head and then update Bazel to use it (I can make that update if that's easier).

cc @bazelbuild/triage

Push a new release containing JDK 21

This PR added support to LTS JDK 21.
After a new version is published, it should be added to BCR and consumed in Bazel per default.

It would be great, if new rules_java release with LTS JDK 21 support would make it in Bazel 7.0 release.

Unrelated here, but apparently, there are some issues overriding the rules_java version shipped in Bazel.

Action external/bazel_tools/tools/jdk/platformclasspath.jar fails with Could not find java.lang.Object on bootclasspath; something has gone terribly wrong.

Bazel 1.2.0

Goal: Compile and run Java source generator with java_binary during Bazel build with specific local Java 8 (ignoring whatever the environment says).

$ cat .bazelrc
build --javacopt="-source 8 -target 8"

build --define=ABSOLUTE_JAVABASE=/Library/Java/JavaVirtualMachines/my-openjdk1.8.0_212.jdk/Contents/Home

No further options defined in .bazelrc.

Here is the full output:

$ bazel build --verbose_failures --sandbox_debug //mypackage:mygenerator
INFO: Analyzed target //mypackage:mygenerator (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
ERROR: /private/var/tmp/_bazel_username/d938ca62e478c52e9a414b5dc35f7a20/external/bazel_tools/tools/jdk/BUILD:309:1: Action external/bazel_tools/tools/jdk/platformclasspath.jar failed (Exit 1) sandbox-exec failed: error executing command
  (cd /private/var/tmp/_bazel_username/d938ca62e478c52e9a414b5dc35f7a20/sandbox/darwin-sandbox/222/execroot/core && \
  exec env - \
    TMPDIR=/var/folders/9h/7v_bq0c55b19253s60bv5ym160zd9f/T/ \
  /usr/bin/sandbox-exec -f /private/var/tmp/_bazel_username/d938ca62e478c52e9a414b5dc35f7a20/sandbox/darwin-sandbox/222/sandbox.sb /var/tmp/_bazel_username/install/3c8c3e061eca79d4c8e8c05bb2875b69/process-wrapper '--timeout=0' '--kill_delay=15' /Library/Java/JavaVirtualMachines/my-openjdk1.8.0_212.jdk/Contents/Home/bin/java -XX:+IgnoreUnrecognizedVMOptions '--add-exports=jdk.compiler/com.sun.tools.javac.platform=ALL-UNNAMED' -cp bazel-out/darwin-fastbuild/bin/external/bazel_tools/tools/jdk/platformclasspath_classes:/Library/Java/JavaVirtualMachines/my-openjdk1.8.0_212.jdk/Contents/Home/lib/tools.jar DumpPlatformClassPath bazel-out/darwin-fastbuild/bin/external/bazel_tools/tools/jdk/platformclasspath.jar external/local_jdk)
Exception in thread "main" java.lang.AssertionError:
Could not find java.lang.Object on bootclasspath; something has gone terribly wrong.
Please file a bug: https://github.com/bazelbuild/bazel/issues
	at DumpPlatformClassPath.writeEntries(DumpPlatformClassPath.java:136)
	at DumpPlatformClassPath.writeClassPathJars(DumpPlatformClassPath.java:174)
	at DumpPlatformClassPath.dumpJDK8BootClassPath(DumpPlatformClassPath.java:77)
	at DumpPlatformClassPath.main(DumpPlatformClassPath.java:65)
Target //mypackage:mygenerator failed to build
ERROR: /private/var/tmp/_bazel_username/d938ca62e478c52e9a414b5dc35f7a20/external/a_repo/.../BUILD:33:1 Action external/bazel_tools/tools/jdk/platformclasspath.jar failed (Exit 1) sandbox-exec failed: error executing command
  (cd /private/var/tmp/_bazel_username/d938ca62e478c52e9a414b5dc35f7a20/sandbox/darwin-sandbox/222/execroot/core && \
  exec env - \
    TMPDIR=/var/folders/9h/7v_bq0c55b19253s60bv5ym160zd9f/T/ \
  /usr/bin/sandbox-exec -f /private/var/tmp/_bazel_username/d938ca62e478c52e9a414b5dc35f7a20/sandbox/darwin-sandbox/222/sandbox.sb /var/tmp/_bazel_username/install/3c8c3e061eca79d4c8e8c05bb2875b69/process-wrapper '--timeout=0' '--kill_delay=15' /Library/Java/JavaVirtualMachines/my-openjdk1.8.0_212.jdk/Contents/Home/bin/java -XX:+IgnoreUnrecognizedVMOptions '--add-exports=jdk.compiler/com.sun.tools.javac.platform=ALL-UNNAMED' -cp bazel-out/darwin-fastbuild/bin/external/bazel_tools/tools/jdk/platformclasspath_classes:/Library/Java/JavaVirtualMachines/my-openjdk1.8.0_212.jdk/Contents/Home/lib/tools.jar DumpPlatformClassPath bazel-out/darwin-fastbuild/bin/external/bazel_tools/tools/jdk/platformclasspath.jar external/local_jdk)
INFO: Elapsed time: 0.460s, Critical Path: 0.23s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

Note, the default Java on the machine is a different one, though. That should not be used for compilation.

$ java --version
openjdk 11.0.4 2019-07-16 LTS
OpenJDK Runtime Environment Zulu11.33+15-NV (build 11.0.4+11-LTS)
OpenJDK 64-Bit Server VM Zulu11.33+15-NV (build 11.0.4+11-LTS, mixed mode)

Flip `incompatible_disallow_empty_glob`

Since incompatible_disallow_empty_glob (bazelbuild/bazel#8195) works globally it would be good ensure core rules repositories conform to this flag. By having this flag flipped in this repo it would regression test this for it's consumers.

When remote execution is enabled, is there anyway to avoid downloading every coverage-runtime_merged_instr.jar?

When performing a Bazel 'coverage' action with remote execution enabled we have found that one of the slowest pieces of repeating builds in our CI/CD pipelines is downloading all the coverage-runtime_merged_instr.jars. These jars get pretty hefty and since every java_test target has its own coverage-runtime_merged_instr.jar it is a bit costly for larger java library/binary targets to split their tests across multiple java_test targets to achieve parallel test runs as each target can be a 300-500mb jar file.

Since these jars are really only necessary on the remote executor side, is there anyway to disable the need for these jars to even be downloaded to the end client? All we really need is the coverage output file(s) not the instrumented JARs on the client side.

How can I get the special version？

I'm having a problem with downloading the rules java package from github, do I use a proxy to download the package and copy it into the machine.

The question is how can I get the special version. For example 981f06c3d2bd10225e85209904090eb7b5fb26bd and how can I get the sha256, then I can use below config to load it.

        http_archive(
            name = "rules_java",
            sha256 = "f5a3e477e579231fca27bf202bb0e8fbe4fc6339d63b38ccb87c2760b533d1c3",
            strip_prefix = "rules_java-981f06c3d2bd10225e85209904090eb7b5fb26bd",
            urls = ["file:///tmp/981f06c3d2bd10225e85209904090eb7b5fb26bd.tar.gz"],
        )

Upload commits to mirror.bazel.build

The commit of rules_java to rules_proto is pinned to is not currently available in mirror.bazel.build. Can someone upload it?

https://github.com/bazelbuild/rules_proto/blob/11bf7c25e666dd7ddacbcd4d4c4a9de7a25175f8/proto/private/dependencies.bzl#L106-L114

Add jmods to jdk targets

One of the features of the jlink command is to allow cross-targetting of jlinked jres. For example, the host jre can target another os/arch via host_jdk/bin/jlink --module-path target_jdk/jmods.

One solution is to add the jmods directory as a filegroup, similar to bin lib include and conf. I've made a PR with this addition here #135.
You would then use it like args.add("--module-path", ctx.attr.target_jdk[java_common.JavaRuntimeInfo].java_home + "/jmods")

Alternatively we could add jmods to the JavaRuntimeInfo class, considering it already has lib_modules via https://bazel.build/rules/lib/providers/JavaRuntimeInfo#lib_modules, perhaps we could add a File JavaRuntimeInfo.jmods.

Support for unused deps with aliases

Currently the unused_deps tool at https://github.com/bazelbuild/buildtools seems to not work with aliases, such as in this situation:

java_library(
    name = "c",
    srcs = ["C.java"],
    deps = [":d2"],
)

alias(
    name = "d2",
    actual = ":d"
)

java_library(
    name = "d",
    srcs = ["D.java"]
)

where C and D are independent of each other.

The unused_deps tool does not report any issues. Changing the dep from ":d2" to ":d" (i.e. no longer using the alias) causes the error to be reported as expected.

What would be the way to support unused_deps correctly reporting unused dependencies reported via aliases? (This issue might also apply to exports, but did not test that).

Does the functionality that java rules provide already give the needed information to make unused_deps work in this situation, or is additional functionality needed?

cc @ittaiz

Java toolchain is not respected

It seems that --java_language_version and related flags are not respected by rules_java.

Expected behaviour: setting the following flags in .bazelrc should build using a Java 17 JDK:

build --java_language_version=17
build --tool_java_language_version=17
build --java_runtime_version=remotejdk_17
build --tool_java_runtime_version=remotejdk_17

Actual behaviour: the build happens with a Java 21 JDK.

Steps to reproduce: see https://github.com/swarren12/example-rules_java.

Specifically: include rules_java by way of bzlmod:

bazel_dep(name = "rules_java", version = "7.0.6", dev_dependency = True)

Create a java_library with sources using Java 17 preview features:

java_library(
    name = "example",
    srcs = glob(["src/main/java/**/*.java"]),
)

Set the properties above in .bazelrc. Attempt to build the code using bazel build //:example.

The build will fail due to:

src/main/java/com/example/Main.java:10: error: patterns in switch statements are not supported in -source 17

Adding the build --javacopt="--enable-preview" property to .bazelrc and re-building causes the following error:

ERROR: BUILD.bazel:4:13: Building libexample.jar (1 source file) failed: (Exit 1): java failed: error executing command (from target //:example) external/rules_java~7.0.6~toolchains~remotejdk21_linux/bin/java '--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED' ... (remaining 19 arguments skipped)
error: invalid source release 17 with --enable-preview

We can see that the build is actually happening on remotejdk21_linux rather than remotejdk17_linux as would be expected.

Why this is important: trying to convert a Gradle project to Bazel and prove correctness. The Gradle project builds on JDK 17 using --enable-preview. If we attempt to set --enable-preview on here, the compiler complains that --enable-preview can only be used with "release 21". Without setting --enable-preview, preview features cannot be used and so the project cannot be migrated "like-for-like" without first being upgraded to Java 21.

Running the build with --toolchain_resolution_debug='@bazel_tools//tools/jdk:runtime_toolchain_type shows the following:

INFO: Build option --toolchain_resolution_debug has changed, discarding analysis cache.
...
INFO: ToolchainResolution:   Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: execution @local_config_platform//:host: Selected toolchain @rules_java~7.0.6~toolchains~remotejdk17_linux//:jdk
...
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: execution platform @local_config_platform//:host: Skipping toolchain @remotejdk17_linux//:jdk; execution platform already has selected toolchain
...
INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/jdk:runtime_toolchain_type -> toolchain @rules_java~7.0.6~toolchains~remotejdk17_linux//:jdk
...
INFO: ToolchainResolution:   Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: execution @local_config_platform//:host: Selected toolchain @rules_java~7.0.6~toolchains~remotejdk17_linux//:jdk
...
INFO: ToolchainResolution:     Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: execution platform @local_config_platform//:host: Skipping toolchain @remotejdk17_linux//:jdk; execution platform already has selected toolchain
...
INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/jdk:runtime_toolchain_type -> toolchain @rules_java~7.0.6~toolchains~remotejdk17_linux//:jdk
...
INFO: ToolchainResolution:   Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: execution @local_config_platform//:host: Selected toolchain @rules_java~7.0.6~toolchains~remotejdk21_linux//:jdk
...
INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/jdk:runtime_toolchain_type -> toolchain @rules_java~7.0.6~toolchains~remotejdk21_linux//:jdk
INFO: Analyzed target //:example (0 packages loaded, 1113 targets configured).
INFO: Found 1 target...

It seems from this that remotejdk17_linux is selected, but then remotejdk21_linux is picked in preference to it. I cannot see any obvious way of excluding remotejdk21_linux from the selection process?

Seems like a similar issue to #95. The solution here was to explicitly define JDKs, but that doesn't feel like the right solution?

Adding `@bazel_tools//tools/java/runfiles` to `rules_java`

Would you welcome a PR that adds the Bazel Java runfiles library, which is available at @bazel_tools//tools/java/runfiles, to rules_java? According to the Starlark "Deploying rules" guide, it should be available at @rules_java//java/runfiles.

I am specifically asking this because I found an issue with the version of the runfiles libraries currently bundled with Bazel and am wondering about how future improvements to these libraries could be published so that users on older Bazel versions could still use them. Especially now that modules exist, rules_java is bound to get far more commonly used and would be a more natural place for modules to get the runfiles library from than @bazel_tools.

rules_java > 7.2.0 incorrectly states it is compatible with Bazel >= 6.4.0

The bazel_compatibility attribute in MODULE.bazel contains >=6.4.0, but it is actually not compatible with 6.4.0. The last version that is compatible with 6.4.0 is [email protected].

See #151 (comment)