Decouple rules_java from java_tools and JDK catalog release cycles #395

Activity

1. meteorcloudy commented on Nov 10, 2026

   

   meteorcloudy

   on Nov 10, 2026

   Member

   More actions

   @hvadehra Does this proposal make sense?
2. davido commented on Nov 12, 2026

   

   davido

   on Nov 12, 2026

   Last edited by davido

   ContributorAuthor

   More actions

   I have extended the prototype with another practical use case: consuming the newly packaged prebuilt ProGuard allowlister.

   I published a personal java_tools snapshot, 23.0-davido.1, including bazelbuild/bazel#32318. This lets me test the new tool without waiting for the official java_tools release requested in bazelbuild/java_tools#104, followed by a combined rules_java release.

   The Gerrit consumer prototype selects:

   bazel_dep(name = "rules_java", version = "9.9.0")
   bazel_dep(name = "java_tools", version = "23.0-davido.1")
   bazel_dep(name = "java_toolchains", version = "0.0.2-catalog.1")
   
   git_override(
       module_name = "rules_java",
       commit = "a6ac7cbd7160104dcb3b7e974ce7d087fdbaeda1",
       remote = "https://github.com/davido/rules_java.git",
   )
   
   git_override(
       module_name = "java_tools",
       commit = "34d71142ce6b94f4434ea42d5fdaeba699e386b8",
       remote = "https://github.com/davido/java_tools.git",
   )
   
   git_override(
       module_name = "java_toolchains",
       commit = "d4de6da36f73dcc0cff2db9fd73a633c4426083d",
       remote = "https://github.com/davido/java_toolchains.git",
   )

   The prebuilt allowlister removes the Java toolchain’s dependency on the Python allowlister and its native zipper. That dependency previously required a Linux C++ toolchain when submitting builds from macOS to Linux RBE workers.

   I rebased the consumer directly onto upstream Gerrit master, excluding the placeholder C++ toolchain workaround, and verified //javatests/com/google/gerrit/json:json_tests:

   • All 12 tests pass locally and on Linux GCP RBE, using JDK 25.0.5.
   • The fresh-output-base RBE run records 136 remote spawn actions, zero action-cache hits, and zero C++ compilation actions.
   • Disk caching, remote action-cache reuse, and local fallback were disabled.
   • All three modules resolve from their published GitHub commits; no local module overrides are used.

   This extension required a one-time rules_java wiring change to select the newly packaged allowlister. After that, compatible tools archive updates can be selected through the independently versioned catalog, without another rules implementation change or combined rules_java release. The JDK catalog remains unchanged.

   That is the release boundary I am proposing: rule/API changes still belong in rules_java, while compatible tools-version updates should be independently releasable.

   While the upstream design remains under discussion, these forks also let me publish and validate experimental snapshots on my own cadence. They are personal GitHub prereleases, not official releases or BCR publications.

   Update

   Another practical result from testing the catalog split: consuming my personal
   java_tools snapshot exposed a previously hidden annotation dependency in
   Gerrit's server_tests. Bazel's intentional JUnit runner dependency cleanup
   removed annotations that the test had been obtaining implicitly. Adding the
   direct dependency fixes it; the affected test class passes with the snapshot.

   I have requested migration-note coverage in
   java_tools#104.

   This supports making tools updates easier to test independently: smaller,
   more frequent updates can help downstream projects discover migration work
   earlier. It is also an argument for more frequent combined rules_java releases;
   this finding alone does not establish that a module split is necessary.

   The consumer prototype remains
   Gerrit change 653343.
   The prebuilt allowlister needs an initial rules_java wiring change; after that
   interface exists, compatible catalog updates can be consumed independently.
3. hvadehra commented on Nov 13, 2026

   

   hvadehra

   on Nov 13, 2026

   Member

   More actions

   Decoupling the toolchains/JDK catalog from rules_java makes sense to me (as I said at #180 (comment)).

   But for java_tools not so much. The java rules are tightly coupled with those so ideally we would have the sources for those in rules_java itself (instead of in Bazel), so we could make changes to both the tools and the rules atomically without worrying about version skew. This is currently blocked on the fact that the compilation actions are still in native Bazel. But there is hope that will change ~soon.
4. davido commented on Nov 13, 2026

   

   davido

   on Nov 13, 2026

   Last edited by davido

   ContributorAuthor

   More actions

   @hvadehra — three questions to scope this:

   1. Name. The SIG meeting suggested jdk_catalog for the extracted module — it's a JDK pin catalog, not a toolchain ruleset (no rules, no load cycle back into rules_java). Any objection from the rules_java side?

   2. java_tools as a first-class, overridable module. Source-coupling aside (agreed tool and rule sources should co-locate eventually), the pain is release latency: a compatible tools bump today needs two serialized releases — a java_tools release, then a combined rules_java release — before anyone downstream can use it. Concretely: the prebuilt ProGuard allowlister drops the Linux C++ toolchain requirement for macOS→Linux RBE, but I could only test it by publishing a personal java_tools snapshot and overriding it — and that same snapshot surfaced a hidden JUnit-annotation dependency in a downstream test earlier than a combined release would have. Would you be OK exposing java_tools as a first-class, overridable BCR module so a bump like that skips the two-release wait? It's already a separate repo on Bazel's cadence — this just makes that boundary a swappable bazel_dep, e.g.:

   bazel_dep(name = "rules_java", version = "10.0.0")
   bazel_dep(name = "java_tools", version = "23.0")   # bump independently, no rules_java release
   bazel_dep(name = "jdk_catalog", version = "1.2.3")

   3. LTS pins in the catalog. OK to move the full JDK pin list — LTS (11/17/21/25) as well as non-LTS (27) — into bazel-contrib/jdk_catalog, with the default catalog still vendored in rules_java so a no-override build is unchanged and external catalogs are purely opt-in?
5. hvadehra commented on Nov 13, 2026

   

   hvadehra

   on Nov 13, 2026

   Member

   More actions

   1. SGTM
   2. The timeframe we're currently targeting for having the native compilation code in Starlark is 2027Q1. We can revisit this if that does not pan out, but for now I don't think it makes sense to make java_tools a BCR module. If the main issue we're trying to solve is the extra rules_java release, ISTM https://bazel.build/external/extension#overriding-and-injecting-module-extension-repos would let (root modules) achieve the same with just a java_tools release.
   3. If the jdk_catalog does not define toolchains, what would the opt-in mechanism would look like for someone wishing to use a non-LTS java_toolchain?
6. davido commented on Nov 13, 2026

   

   davido

   on Nov 13, 2026

   Last edited by davido

   ContributorAuthor

   More actions

   If the jdk_catalog does not define toolchains, what would the opt-in mechanism would look like for someone wishing to use a non-LTS java_toolchain?

   jdk_catalog defines no new toolchain rules — it loads rules_java's own rules and just instantiates the non-LTS toolchain with them:

   https://github.com/davido/jdk_catalog/blob/main/toolchains/BUILD.bazel#L1-L29

   load("@rules_java//toolchains:default_java_toolchain.bzl",
         "DEFAULT_TOOLCHAIN_CONFIGURATION", "default_java_toolchain")
   load("@rules_java//toolchains:java_toolchain_alias.bzl",
        "java_runtime_version_alias")

   So "not a toolchain ruleset" holds (no new rule types, no fork, reuses rules_java's machinery) — "defines no toolchains" was my imprecision. It defines the non-LTS toolchain instances: a java_runtime_version_alias (remotejdk_27 runtime) and a default_java_toolchain (toolchain_jdk_27, javac on JDK 27 — the LTS toolchains' javac tops out at 25 and rejects source/target 27). The non_lts_jdks module extension registers both.

   Opt-in is just bazel_dep(name = "jdk_catalog") + --java_runtime_version=remotejdk_27 (or --java_language_version=27); no manual register_toolchains. A consumer that already wires its own toolchain (Gerrit, for Error Prone) can instead build its own default_java_toolchain on top of @jdk_catalog//toolchains:remotejdk_27.

   For the working end to end example you can see:

   https://gerrit-review.googlesource.com/c/gerrit/+/637823/16/tools/BUILD#26

   I hope that clarifies it?
7. fmeum commented on Nov 13, 2026

   

   fmeum

   on Nov 13, 2026

   Contributor

   More actions

   Please take note of bazelbuild/bazel#32428, which will make it so that jdk_catalog can't register its Java toolchains directly, the root module will have to do that explicitly. This could be as simple as register_toolchains("@jdk_catalog//:all").