You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While we have added STS java releases in the past, we've also been dropping them, keeping only the LTS ones around. This probably ends up creating too much churn, and unnecessary breakage on updating rules_java.
I think it's somewhat trivial for users of rules_java to declare the repository(ies) themselves using remote_java_repository.
@davido Is there any added benefit to the declarations living in rules_java?
@hvadehra tbh now that it's 2026 with the advent of coding agents, I don't think the churn is that high. I am working with a lot of enterprise Bazel users who prefer to keep their dependencies as close to HEAD as possible to benefit from security fixes as well as performance improvements. This ranges from the kernel version to glibc, clang, as well as JDK.
Adding support for JDK 27 into rules_java would let these users enable this via the existing flags instead of having to maintain the custom toolchains themselves. Accumulatively, it should reduce churn for the entire ecosystem, not the other way around.
instead of having to maintain the custom toolchains
could also be met with
it's 2026 with the advent of coding agents
/scnr
I could see the argument for having this in rules_java with WORKSPACE a few years ago. Today if you wish to avoid duplication, a sluongng_java_toolchains1 BCR module seems simple enough?
Footnotes
now that we have bzlmod, the java toolchain definitions should maybe be moved out into a separate module anyways ↩
This is actually what is already happening today, with a lot of <user|org>_rules_java_fork being maintained internally in each org. I do think there is value in deduplicating these efforts in a centralized place, though.
Do I understand correctly that the best course of action would be to to move toolchain declarations out of rules_java into an official rules_java_toolchains module? How much work is that?
Do I understand correctly that the best course of action would be to to move toolchain declarations out of rules_java into an official rules_java_toolchains module? How much work is that?
A community maintained module (perhaps under bazel-contrib) is what I'm envisaging. But it's possible I'm missing the downsides of small, composable modules rather than monolithic ones?
Activity
hvadehra commentedon May 8, 2024
While we have added STS java releases in the past, we've also been dropping them, keeping only the LTS ones around. This probably ends up creating too much churn, and unnecessary breakage on updating
rules_java.I think it's somewhat trivial for users of
rules_javato declare the repository(ies) themselves usingremote_java_repository.@davido Is there any added benefit to the declarations living in
rules_java?sluongng commentedon Oct 2, 2026
@hvadehra tbh now that it's 2026 with the advent of coding agents, I don't think the churn is that high. I am working with a lot of enterprise Bazel users who prefer to keep their dependencies as close to HEAD as possible to benefit from security fixes as well as performance improvements. This ranges from the kernel version to glibc, clang, as well as JDK.
Adding support for JDK 27 into rules_java would let these users enable this via the existing flags instead of having to maintain the custom toolchains themselves. Accumulatively, it should reduce churn for the entire ecosystem, not the other way around.
So I strongly urge the team to reconsider this.
cc: @meisterT
hvadehra commentedon Oct 2, 2026
could also be met with
/scnr
I could see the argument for having this in
rules_javawithWORKSPACEa few years ago. Today if you wish to avoid duplication, asluongng_java_toolchains1 BCR module seems simple enough?Footnotes
now that we have bzlmod, the java toolchain definitions should maybe be moved out into a separate module anyways ↩
sluongng commentedon Oct 2, 2026
This is actually what is already happening today, with a lot of
<user|org>_rules_java_forkbeing maintained internally in each org. I do think there is value in deduplicating these efforts in a centralized place, though.meisterT commentedon Oct 5, 2026
Do I understand correctly that the best course of action would be to to move toolchain declarations out of rules_java into an official rules_java_toolchains module? How much work is that?
hvadehra commentedon Oct 5, 2026
A community maintained module (perhaps under
bazel-contrib) is what I'm envisaging. But it's possible I'm missing the downsides of small, composable modules rather than monolithic ones?davido commentedon Oct 5, 2026
I put together a
rules_java_toolchainsBazel module and consumed it in Gerrit.Happy to move it under bazel-contrib and publish to the BCR if that's the direction.