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

Most upvoted comments

@bazel-io fork 6.5.0

@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) and javac --add-opens=... Foo.java (without -J it’s a regular javac flag).

One more question: are future bugfix releases planned for 6.x? like 6.4.1 / 6.5.0? Or will the release of 7.0.0 mean that 6.x is no longer supported

https://bazel.build/release#support-matrix

@iancha1992 that’s fine, thanks for letting me know!

@bazel-io fork 7.0.0

Lucky timing! Could you also backport the PR to 7.x and also ideally 6.x if possible?