Cannot fix or prevent javac fallbacks when using --experimental_java_classpath=bazel

[rsalvador]

Description of the feature request:

Introduce an option to fail the build if javac fails to compile with the reduced classpath while using --experimental_java_classpath=bazel.

Which category does this issue belong to?

Java Rules

What underlying problem are you trying to solve with this feature?

In our large Java monolith, certain modules often fail to compile with the reduced classpath, triggering an additional build action with the full transitive classpath. We want to fix these fallbacks but need a way to identify the reasons for their occurrence. By failing the build, this feature would:

1. Expose javac errors and identify missing dependencies.
2. Prevent new fallbacks from being introduced.

Which operating system are you running Bazel on?

MacOS and Linux

What is the output of bazel info release?

7.4.1

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 HEAD ?

No response

Have you found anything relevant by searching the web?

No

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

No response

[hvadehra]

cc @cushon

[cushon]

I am interested in understanding more about the use-case. Do you want to use this just to clean up reduced classpath fallbacks, or for all of your builds? What has your experience been trying to fix these, I'm curious how often it came up, and what approach you took to fixing them? Did you generally just add additional deps?

Some notes:

Some of the same issues as #16426 (comment) apply to preventing fallbacks from happen, although they'd be rarer than with the direct-deps-only approach discussed in the other issue.

Fallback can happen for reasons like the compiler needing a transitively referenced symbol in an overload of a method when doing overload resolution. If the dependency changes the set of overloads, that could affect fallback. It can also change between compiler versions. Making it an error could be fragile.

There isn't always a good fix. Something it's possible to just add deps, but other times the compiler needs to load a symbol that's a private implementation detail of a dependency, and adding a dep would require relaxing build visibility.

It's also in tension with strict deps, since it requires adding additional dependencies that aren't directly referenced and wouldn't otherwise needed, and could become unused in the future. It's hard for other dependency management tools to reason about, since there's no direct reference to types that the additional dependencies are being added for.

[There's some overlap with internal bug b/124334239]

[rsalvador]

Initially we want to use it to just clean reduced classpath fallbacks. But may enable it by default at some point, so all checked in source is clean of fallbacks.

A few fallbacks are introduced every month. We notice them by the duplicate build actions they generate, and fix them periodically by running locally a patched bazel version that has the change in the PR. Almost all of the errors are missing classes that are solved by adding a dependency.