Additional context is provided in #19872 (comment).

@bazel-io fork 7.1.0

@hvadehra Btw, does Google use all three modes of --java_classpath? I'm wondering whether it would make sense to flip the default for Bazel to bazel (from javabuilder).

1. I'm a little unsure about this change. IIUC this change tries to derive the value of insertDependencies from the presence of JavaCompileActionContext/JdepsCachingActionContext. But those need not be the same, given L374-377. So, after this change, we'd be populating the cache even in those cases where we turn off the bazel classpath mode. I don't know if this would matter in practice, but given that this check was explicitly introduced in 5f9e9f0, I'd like @gregestren to have a look as well.

2. I haven't looked at the details of the regression discussed in Also path map transitive header jar paths with direct classpath optimization #19872 (comment) but looking at the numbers, I estimate the contribution of the extra field is ~5% of the total regression. This might actually be an acceptable number. I'd recommend tackling the rest first, and then adding this change on if necessary later. In any case, if there is a O(days) gap between merging this change and the rollforward, that latter may still be flagged as a regression since the baseline for measurement will include this change. So, having both ready to be merged together will make things simpler.

3. The default for --java_classpath internally is bazel as well, and that's the mode used by almost all builds (a small number (0.007%) do use the javabuilder mode, but I'll have to investigate to see why). So flipping the default should be mostly a no-op internally and SGTM.

Thanks for sharing more numbers, I agree that this particular change is less important in this case. I will look into the more pressing problem first.

Could you link to the lines you referred to as L374-377? I meant for this PR to register the context exactly when using bazel, which was the condition that insertDependencies encoded.

Could you link to the lines you referred to as L374-377

I'd meant to do that but forgot, sorry about that: https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/java/JavaHeaderCompileAction.java#L373-L377

Thanks, now I fully understand your comment. This logic does make it difficult to replace the field, assuming it is needed at all.

I will close this PR for now and think about how to prevent the large part of the regression.

I will also look into submitting a PR to flip the default classpath mode for Bazel.