bazel: Java `--add-opens` should not be passed to javac; breaks with `-Werror`
Description of the bug:
If a target is declared with an add_opens
attribute, it appears that the --add-opens
flag is getting passed to javac
. But this is incorrect, as --add-opens
is a runtime-only flag. The consequence is that if -Werror
is part of javacopts
and JDK ≥17 is used, then build will fail. See reproduction case below.
Which category does this issue belong to?
Java Rules
What’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
https://github.com/timothyg-stripe/bazel-add-opens-repro
bazel-add-opens-repro timothyg$ bazel version
Build label: 6.3.2
Build target: bazel-out/darwin_arm64-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Aug 8 15:51:44 2023 (1691509904)
Build timestamp: 1691509904
Build timestamp as int: 1691509904
bazel-add-opens-repro timothyg$ cat .bazelrc
build --java_language_version=17 --javacopt=-Werror
bazel-add-opens-repro timothyg$ bazel build //:TestMain
INFO: Analyzed target //:TestMain (1 packages loaded, 3 targets configured).
INFO: Found 1 target...
ERROR: ~/bazel-add-opens-repro/BUILD.bazel:1:13: Building libtest.jar (1 source file) failed: (Exit 1): java failed: error executing command (from target //:test) external/remotejdk17_macos_aarch64/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 18 arguments skipped)
warning: [options] --add-opens has no effect at compile time
error: warnings found and -Werror specified
Target //:TestMain failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.782s, Critical Path: 0.66s
INFO: 4 processes: 3 internal, 1 worker.
FAILED: Build did NOT complete successfully
cc @cushon who wrote 2217b13cae4110b0e2b8fe6a283a9b6dfbf150e8
Which operating system are you running Bazel on?
macOS
What is the output of bazel info release
?
release 6.3.2
If bazel info release
returns development version
or (@non-git)
, tell us how you built Bazel.
No response
What’s the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD
?
No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
About this issue
- Original URL
- State: closed
- Created 8 months ago
- Comments: 18 (18 by maintainers)
Commits related to this issue
- Don't pass `--add-opens=` to javac They are unnecessary at compile-time, and this avoids a warning on recent javac versions: ``` warning: [options] --add-opens has no effect at compile time ``` The... — committed to bazelbuild/bazel by cushon 8 months ago
- Don't pass `--add-opens=` to javac They are unnecessary at compile-time, and this avoids a warning on recent javac versions: ``` warning: [options] --add-opens has no effect at compile time ``` The... — committed to iancha1992/bazel by cushon 8 months ago
- [7.0.0] Don't pass `--add-opens=` to javac (#20016) They are unnecessary at compile-time, and this avoids a warning on recent javac versions: ``` warning: [options] --add-opens has no effect at ... — committed to bazelbuild/bazel by iancha1992 8 months ago
@bazel-io fork 6.5.0
@bazel-io fork 6.0.0
This is fixed by https://github.com/bazelbuild/bazel/commit/367994ab9f3bb8d06a39d6bd0c139f00dcf47f3e, right?
@guw this PR should be a no-op, passing
--add-opens
as a command line argument to javac doesn’t do anything. If an annotation processor was reflecting on internal JDK APIs, it would need--add-opens
to be passed as a runtime JVM flag to javac, which is still possible.i.e. this is the difference between
javac -J--add-opens= Foo.java
(-J
means the flag is passed as a VM argument) andjavac --add-opens=... Foo.java
(without-J
it’s a regular javac flag).https://bazel.build/release#support-matrix
@iancha1992 that’s fine, thanks for letting me know!
@bazel-io fork 7.0.0
@bazel-io flag
Lucky timing! Could you also backport the PR to 7.x and also ideally 6.x if possible?