rules_closure (and Gerrit) fails on Bazel@HEAD with @bazel_tools//tools/jdk:toolchain_java9

[davido]

Trying to build rule_closure on most recent master (3555e5ba61fdcc17157dd833eaf7d19b313b1bca), and Gerrit with JDK9 on Bazel@HEAD(398478c) is failing with the same error:

  $ java -fullversion
  openjdk full version "9.0.4+12-suse-4.2-x8664"

  $ bazel test --host_java_toolchain=@bazel_tools//tools/jdk:toolchain_java9 --java_toolchain=@bazel_tools//tools/jdk:toolchain_java9 //closure/...
INFO: Analysed 1236 targets (0 packages loaded).
INFO: Found 1161 targets and 75 test targets...
ERROR: /home/davido/projects/rules_closure/java/io/bazel/rules/closure/BUILD:17:1: Building java/io/bazel/rules/closure/ClosureWorker.jar (1 source file) and running annotation processors (ComponentProcessor) failed (Exit 1)
Note: Multiple elements named 'javax.annotation.processing.Generated' in modules 'java.base, java.compiler, jdk.accessibility, java.desktop, java.datatransfer, java.xml, java.prefs, jdk.dynalink, java.logging, jdk.jartool, jdk.jsobject, jdk.jconsole, jdk.management.agent, java.management.rmi, java.naming, java.security.sasl, java.rmi, java.management, jdk.attach, jdk.management, jdk.jdi, jdk.jdwp.agent, jdk.net, jdk.xml.dom, jdk.httpserver, jdk.scripting.nashorn, java.scripting, jdk.unsupported, jdk.security.auth, java.security.jgss, jdk.sctp, jdk.security.jgss, java.sql.rowset, java.sql, java.instrument, java.xml.crypto' were found by javax.lang.model.util.Elements.getTypeElement.
Note: Multiple elements named 'javax.annotation.Generated' in modules 'java.base, jdk.accessibility, java.desktop, java.datatransfer, java.xml, java.prefs, jdk.dynalink, java.logging, jdk.jartool, jdk.jsobject, jdk.jconsole, jdk.management.agent, java.management.rmi, java.naming, java.security.sasl, java.rmi, java.management, jdk.attach, jdk.management, jdk.jshell, jdk.jdi, jdk.jdwp.agent, jdk.compiler, java.compiler, jdk.net, jdk.xml.dom, jdk.httpserver, jdk.scripting.nashorn, java.scripting, jdk.unsupported, jdk.security.auth, java.security.jgss, jdk.sctp, jdk.javadoc, jdk.security.jgss, java.se, java.sql.rowset, java.sql, java.instrument, java.xml.crypto' were found by javax.lang.model.util.Elements.getTypeElement.
bazel-out/host/bin/java/io/bazel/rules/closure/_javac/ClosureWorker/ClosureWorker_sourcegenfiles/io/bazel/rules/closure/DaggerClosureWorker_Server.java:145: error: [strict] Using type io.bazel.rules.closure.webfiles.compiler.CssParser from an indirect dependency (TOOL_INFO: "//java/io/bazel/rules/closure/webfiles/compiler"). See command below **
          DaggerClosureWorker_Server.this.fs, new CssParser());
                                                  ^
 ** Please add the following dependencies: 
  //java/io/bazel/rules/closure/webfiles/compiler to //java/io/bazel/rules/closure:ClosureWorker 
 ** You can use the following buildozer command: 
buildozer 'add deps //java/io/bazel/rules/closure/webfiles/compiler' //java/io/bazel/rules/closure:ClosureWorker 

INFO: Elapsed time: 3.400s, Critical Path: 1.82s
INFO: 15 processes: 12 linux-sandbox, 3 worker.
FAILED: Build did NOT complete successfully

//CC @cushon

[davido]

It seems that this diff fixed that:

diff --git a/java/io/bazel/rules/closure/BUILD b/java/io/bazel/rules/closure/BUILD
index e8d1003..acf13f2 100644
--- a/java/io/bazel/rules/closure/BUILD
+++ b/java/io/bazel/rules/closure/BUILD
@@ -26,6 +26,7 @@ java_binary(
     deps = [
         "//java/com/google/javascript/jscomp",
         "//java/io/bazel/rules/closure/webfiles",
+        "//java/io/bazel/rules/closure/webfiles/compiler",
         "//java/io/bazel/rules/closure/worker",
         "@com_google_dagger",
         "@com_google_guava",

[cushon]

Adding the dep is a fine work-around, but it shouldn't be necessary.

Strict Deps ignores some dagger generated code:

bazel/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/javac/plugins/dependency/StrictJavaDepsPlugin.java

Line 418 in b470c0f

if (value.startsWith(DAGGER_PROCESSOR_PREFIX)) {

Dagger uses this utility to pick a version-appropriate @Generated annotation: https://github.com/google/auto/blob/9cc04ecb39166207a2835174b85ee209cc08aad0/common/src/main/java/com/google/auto/common/GeneratedAnnotations.java#L54

That logic is failing on JDK 10 with --release 9 due to an apparent javac bug: https://bugs.openjdk.java.net/browse/JDK-8209865

[davido]

This was apparently fixed in 3987300?

[cushon]

JDK-8209865 remains unfixed, but 3987300 works around it by not using the flag.

[davido]

Thanks, @laurentlb cherry-picked 3987300 in upcoming 0.17.0 release so that it's fine to close this issue.

[davido]

but 3987300 works around it by not using the flag.

Could you clarify how the mentioned workaround is able to produce JDK 8 (or JDK 9) byte code using embedded JDK10, without using --release 8|9 flag?

[cushon]

-source/-target/-bootclasspath are still supported and allow targeting the Java 8 (or 9) language level, and using them instead of --release avoids JDK-8209865.

[davido]

Thanks for clarifying.