Java compilation always fails with strict deps errors with bzlmod

[fmeum]

Description of the bug:

As of 34a4f13, when using Bzlmod, every Java compilation fails with a strict deps error.

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

$ git clone https://github.com/fmeum/rules_jni
$ cd rules_jni
$ git checkout b71248be4c74ef305c1d0b8c3405a5800584d486
$ USE_BAZEL_VERSION=2fbed806cc28712d67846ac3e22ad5738b519d02 bazel build --config=bzlmod //jni/tools/native_loader/src/main/java/com/github/fmeum/rules_jni:native_library_info
...
INFO: Build completed successfully, 4 total actions
$ USE_BAZEL_VERSION=34a4f13958ee225390af6f8450e3edad9ccf9acb bazel build --config=bzlmod //jni/tools/native_loader/src/main/java/com/github/fmeum/rules_jni:native_library_info
...
ERROR: /home/fhenneke/git/rules_jni/jni/tools/native_loader/src/main/java/com/github/fmeum/rules_jni/BUILD.bazel:40:13: Building jni/tools/native_loader/src/main/java/com/github/fmeum/rules_jni/libnative_library_info.jar (1 source file) failed: (Exit 1): java failed: error executing command (from target //jni/tools/native_loader/src/main/java/com/github/fmeum/rules_jni:native_library_info) 'external/@rules_java~5.0.0~toolchains~remotejdk11_linux/bin/java' -XX:-CompactStrings '--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED' ... (remaining 18 arguments skipped)
jni/tools/native_loader/src/main/java/com/github/fmeum/rules_jni/NativeLibraryInfo.java:20: error: [strict] Using type java.lang.String from an indirect dependency (TOOL_INFO: "/home/fhenneke/.cache/bazel/_bazel_fhenneke/0b03dcd5b44da4057874286978352151/execroot/fmeum_rules_jni/bazel-out/k8-fastbuild/bin/external/@rules_java~5.0.0/toolchains/platformclasspath.jar").
  public final String canonicalPath;
               ^
Target //jni/tools/native_loader/src/main/java/com/github/fmeum/rules_jni:noop_coverage_helper failed to build

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

HEAD

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

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

I augmented JavaBuilder with some additional debug output and noticed that with the failing commit, the jarPath here is absolute, whereas the entries in directJars and platformJars are relative to the exec root. With the commit before the failing commit, the jarPath is relative.

I unfortunately didn't find the place where paths containing ~ would be handled specially in the JDK and/or JavaBuilder.

[fmeum]

@cushon While the superficial cause is using Bzlmod, the root cause appears to be that paths containing tildes are treated specially by either javac or JavaBuilder. Do you have an idea why?

CC @Wyverald, maybe ~ isn't as safe as previously thought.

[Wyverald]

I did some more testing. The follow minimal repro case:

$ touch MODULE.bazel
$ touch WORKSPACE
$ echo 'java_library(name="hello",srcs=["Hello.java"])' > BUILD
$ echo 'class Hello { String a; }' > Hello.java
$ bazel build --experimental_enable_bzlmod :hello 

... already throws the same error about String being from an indirect dependency.

However, if I don't enable Bzlmod, everything compiles and runs perfectly even if I set up a source directory that contains tildes. I tried package directory names containing tildes (//my~pkg:target), external repos containing tildes in their path (@foo//:target with foo being backed by the path my~foo), and even combinations of the above. Nothing repros the failure.

So I'm inclined to think that somehow rules_java being located in a directory whose path contains ~ causes the error.

[cushon]

With --experimental_enable_bzlmod, it's using a different JDK version

$ external/@rules_java~5.0.0~toolchains~remotejdk11_linux/bin/java
openjdk full version "11.0.12+7-LTS"

vs

$ external/remotejdk11_linux/bin/java
openjdk full version "11.0.15+10-LTS"

Strict Java Deps depends on a bug fix in JDK 11: #14533.

With --experimental_enable_bzlmod, it's also passing --patch-module= flags that are supported to patch in a javac version with a bug fix. We removed that work-around as part of the bug I linked. I'm suspicious that configuration isn't working correctly:

bazel aquery --experimental_enable_bzlmod 'mnemonic(Javac, :hello)'
...
    '--patch-module=java.compiler='\''external/@rules_java~5.0.0~toolchains~remote_java_tools/java_tools/java_compiler.jar'\''' \
    '--patch-module=jdk.compiler='\''external/@rules_java~5.0.0~toolchains~remote_java_tools/java_tools/jdk_compiler.jar'\''' \

I'm not sure where the different in JDK version and --patch-module= flags with --experimental_enable_bzlmod is coming from, maybe it's using an old version of rules_java?

[Wyverald]

Hmm... interesting how this bug only surfaces with the tildes, then.

With Bzlmod enabled, the remote JDK is coming from rules_java 5.0.0, which is the latest release version, but doesn't contain bazelbuild/rules_java@36a7611, which updates the JDK versions to match what Bazel uses itself (without Bzlmod, that is).

So we should be good if we just release a new version of rules_java. I'll look into that.

Thanks for your help, Liam!