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
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:
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?
The text was updated successfully, but these errors were encountered:
cc @meteorcloudy looks like some of the translated pages are broken.
How can I tell rules_java and Bazel and everything in the goddamn monorepo that I want to use a local JVM?
The critical bit is there are generally two java runtimes, one in the target config (running your compiled java code) and one for the exec/tool config (running java tools as part of the build itself). See bazelbuild/bazel#19934 (comment) for more.
By default, Bazel uses the local_jdk as the target runtime, and a remote_jdk for exec/tool. This is because using a local jdk for tools would interact badly with remote execution. More generally, using a local jdk is best avoided (even for the target config), since it breaks hermeticity. If you absolutely must, see bazelbuild/bazel#21752 (comment)
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:
@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?The text was updated successfully, but these errors were encountered: