bazel: --strict_java_deps=warn regression in 0.18x

Description of the problem / feature request:

We have code which is being compiled via java_common.compile. 0.17.2 running with --strict_java_deps=warn emits a warning (warning: [strict] Using type org.atmosphere.wasync.impl.AtmosphereClient from an indirect dependency (TOOL_INFO: "external/org_atmosphere_wasync/wasync-2.1.5.jar").) we parse that and add the relevant buildozer strict-deps instructions. In 0.18.1 (and in 0.19.0) running with --strict_java_deps=warn does not emit this warning but fails (error: symbol not found org.atmosphere.wasync.impl.AtmosphereClient import org.atmosphere.wasync.impl.AtmosphereClient; ) In 0.18.1- I looked in the relevant bazel-out folder and I see that in foo_java-hjar.jar-0.params the external dependency is missing while in foo_java.jar-0.params it exists. In 0.17.2- the external dependency exists in both of the above files. This leads me to suspect something has changed in the classpath being sent to javac when building the ijar (maybe it’s turbine and not javac, not sure).

Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I’m working on a repro. Not sure it surfaces easily in an extracted piece but I’ll try. I will also try to see if I can repro this on java_library because we can always suspect the starlark middleman (java_common.compile)

cc @cushon @iirina

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 29 (27 by maintainers)

Commits related to this issue

Make flag control of --strict_java_deps experimental to clarify the level of support for flag control of the feature, which remains enabled by default. Related: #6580 RELNOTES: --strict_android_dep... — committed to bazelbuild/bazel by cushon 6 years ago

Most upvoted comments

I would actually prefer not having --strict_java_deps=warn at all – warnings have a tendency to be ignored, so in my experience, their utility is very limited.

lberki on Nov 6, 2018

java_toolchain.javac is a legacy attribute and shouldn’t have an effect either way.

The canonical --host_javabase=<jdk8>-compatible toolchain is @bazel_tools//tools/jdk:toolchain_hostjdk8:

https://github.com/bazelbuild/bazel/blob/f8be43cebfe5d9ee80e838c883fb305969ece743/tools/jdk/BUILD#L209-L215

cushon on Nov 3, 2018

ok, that was lengthy, unpleasant and tedious but we have a carved out minimal repro 😃 https://github.com/ittaiz/strict-deps-regression-18.1 bazel build //... with 0.17.2 => build completes successfully with a turbine warning + strict-deps warning bazel build //... with 0.18.1 => build fails to complete Note that you should symlink your jdk to /usr/local/lib/jvm/java-8-latest since that’s where the java_runtime is pointing to and for me that is

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

ittaiz on Nov 2, 2018