Header compilation doesn't work on Java 11 source code

[gmishkin]

Description of the problem / feature request:

Recently started using the Bazel 0.27 release candidates to try out the default Java toolchain with our Java 11 code base, passing --javacopt="--release 11" to build. But when something depends on one of these targets, it tries to build an hjar, and that fails with errors about language features that are newer than Java 8.

Compiling Java headers server/src/main/libmain-hjar.jar (4762 files) and running annotation processors (AnnotationProcessorHider$AnnotationProcessor) failed (Exit 1) java failed: error executing command external/remotejdk11_macos/bin/java -Xverify:none -XX:+UseParallelOldGC -XX:-CompactStrings '--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED' ... (remaining 14 argument(s) skipped)
...
error: variables in try-with-resources are not supported in -source 8

Details from --sandbox_debug:

external/remotejdk11_macos/bin/java -Xverify:none -XX:+UseParallelOldGC -XX:-CompactStrings '--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED' '--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED' '--patch-module=java.compiler=external/remote_java_tools_darwin/java_tools/java_compiler.jar' '--patch-module=jdk.compiler=external/remote_java_tools_darwin/java_tools/jdk_compiler.jar' '--add-opens=java.base/java.nio=ALL-UNNAMED' '--add-opens=java.base/java.lang=ALL-UNNAMED' -jar external/remote_java_tools_darwin/java_tools/turbine_deploy.jar @bazel-out/darwin-fastbuild/bin/server/src/main/libmain-hjar.jar-0.params)

Snippet from params:

--javacopts
-source
8
-target
8
-XDskipDuplicateBridges=true
-g
-parameters
--release
11
--
--target_label
//server/src/main:main

If I delombok our code and run without annotation processing, it works. It seems like it's using the other turbine implementation.

Feature requests: what underlying problem are you trying to solve with this feature?

Will the turbine implementation that's used when you have annotation processors be updated to handle Java 11 language features, or any other workaround?

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

https://github.com/gmishkin/bazel_8585

What operating system are you running Bazel on?

macOS 10.14.5

What's the output of bazel info release?

release 0.27.0rc3

Have you found anything relevant by searching the web?

Just that there are two different turbine implementations and one of them seems to have -source 8 hardcoded so maybe this is on purpose.

[davido]

Is this related to 6ef6d87 that was added in 0.27.0rc3? Does it work with 0.27.0rc2?

[gmishkin]

Nope, tried that, set up a minimal reproduction here: https://github.com/gmishkin/bazel_8585

[iirina]

I looked into it and discovered that Turbine always builds the compile time jars for Java 8 (JavacTurbine.java#L245) @cushon is this still the case? Is there a way to override the javacopts for Turbine or do you see any issues with overriding them?

[iirina]

@cushon friendly ping :) Why does Turbine make the assumption that compile-time jars always use Java 8?

[cushon]

Only because we haven't started to use Java 11 internally yet; it needs to be fixed to support 11.

[MuminKhan]

I think I'm hitting the same issue in Bazel 1.1.0. @iirina / @cushon do you know if there's a timeline for this?

[MuminKhan]

Bump @iirina and @cushon

[brown]

I'm seeing this problem with Bazel 1.0.1. We have Java 11 source code and it's interfering with our ability to upgrade to a recent version of Bazel. We are using the default remote Java 11 toolchain. The params file for the turbine invocation contains "-source 11" but the code appears to override that to version 8.

[cnaj]

Note for users having the same problem: As a workaround you can disable header compilation using the --java_header_compilation=false switch (Bazel 2.0.0).

[cheister]

Any update on a timeline for this issue? Thanks.

[Ubehebe]

This is an issue with Java 14 as well. I am upgrading my codebase to use Java 14 switch expressions. I was able to get most of the way with a java_toolchain configured with {source,target}_version = "14". However, changing switch statements to expressions in Dagger modules triggered the error similar to the OP.

I mention Dagger because Bazel has hardcoded logic for enabling Turbine when Dagger's annotation processor is being used. That code links to a Google-internal bug (b/31371210).

The workaround in my case was the same as the OP's: --nojava_header_compilation.

This was a surprising issue to run into, because java_toolchain is intended to be the top-level API for working with Java versions. The fact that Java 8 is still involved in my build was unexpected.

[cushon]

cc @comius since this relates to Java >= 11 support

[cushon]

Java 11 source should be fully supported in turbine as of 10ffddb