Bazel apparently using wrong host JDK

Description of the problem / feature request:

Caveat: I’ve been doing my best to read and understand Bazel’s documentation for the three different Java environments, and toolchains, and so forth. So perhaps this winds up being a documentation request issue.

I’ve been having a hard time getting Bazel to build using jdk8 as the host jdk, and don’t think I’ve had success doing so. I only have jdk8 installed on my system:

david:code davidsantiago$ `which javac` -version
javac 1.8.0_131

But when I run bazel build ... -java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8, it apparently doesn’t use jdk8. The reasons I think this are

1. I get a build error in Kotlin that happens when using jdk11
2. bazel info also thinks I am using jdk11:

$ bazel info --java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8 --verbose_failures
...
java-home: /private/var/tmp/_bazel_davidsantiago/install/1a037b6c0d8096293d1eecfde6528fbd/_embedded_binaries/embedded_tools/jdk
java-runtime: OpenJDK Runtime Environment (build 11.0.2+7-LTS) by Azul Systems, Inc.
java-vm: OpenJDK 64-Bit Server VM (build 11.0.2+7-LTS, mixed mode) by Azul Systems, Inc.
...

1. When I run my build command with the --toolchain_resolution_debug flag, it repeatedly says

INFO: ToolchainResolver: Selected execution platform @bazel_tools//platforms:host_platform, type @bazel_tools//tools/jdk:toolchain_type -> toolchain @bazel_tools//tools/jdk:dummy_toolchain

Which, I’m not sure what it is, but it is not what I asked for with the --java_toolchain flag above.

So I’m having a hard time thinking I’m not building with jdk11 as the host jdk, or at least I can’t find any reason to think otherwise. I think I’ve followed the docs, though I admit my understanding of the intricacies here is totally sketchy.

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

I can see this just by running bazel info or bazel info --java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8 or any of the other plausibly jdk8 toolchains defined in that package.

I’m running Bazel 0.25.2, which I installed via brew install bazelbuild/tap/bazel, on Mac OS X 10.14.4.

I’m using these kotlin build rules, and I realize that might have some involvement here. However, I don’t think you need to reach the kotlin rules to see this issue, as evidenced by the bazel info command above. Also, I get the exact same java toolchain resolution messages from running

bazel build --java_toolchain=@bazel_tools//tools/jdk:toolchain_hostjdk8 examples/java-skylark/... --toolchain_resolution_debug

in the bazel repo, although that one will build successfully. Interestingly, if I try it on the java-native example instead, I get a build error using the --java_toolchain flag as above:

... Selected execution platform ... @bazel_tools//tools/jdk:dummy_toolchain blah blah blah ...
ERROR: /Users/davidsantiago/Documents/Work/bazel/examples/java-native/src/main/java/com/example/myproject/BUILD:3:1: Building examples/java-native/src/main/java/com/example/myproject/hello-world.jar () failed: Worker process returned an unparseable WorkResponse!

Did you try to print something to stdout? Workers aren't allowed to do this, as it breaks the protocol between Bazel and the worker process.

---8<---8<--- Exception details ---8<---8<---
com.google.protobuf.InvalidProtocolBufferException$InvalidWireTypeException: Protocol message tag had invalid wire type.
	at com.google.protobuf.InvalidProtocolBufferException.invalidWireType(InvalidProtocolBufferException.java:115)
	at com.google.protobuf.UnknownFieldSet$Builder.mergeFieldFrom(UnknownFieldSet.java:551)
	at com.google.protobuf.GeneratedMessageV3.parseUnknownFieldProto3(GeneratedMessageV3.java:305)
	at com.google.devtools.build.lib.worker.WorkerProtocol$WorkResponse.<init>(WorkerProtocol.java:1936)
	at com.google.devtools.build.lib.worker.WorkerProtocol$WorkResponse.<init>(WorkerProtocol.java:1886)
	at com.google.devtools.build.lib.worker.WorkerProtocol$WorkResponse$1.parsePartialFrom(WorkerProtocol.java:2503)
	at com.google.devtools.build.lib.worker.WorkerProtocol$WorkResponse$1.parsePartialFrom(WorkerProtocol.java:2497)
	at com.google.protobuf.AbstractParser.parsePartialFrom(AbstractParser.java:221)
	at com.google.protobuf.AbstractParser.parsePartialDelimitedFrom(AbstractParser.java:262)
	at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:275)
	at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:280)
	at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:49)
	at com.google.protobuf.GeneratedMessageV3.parseDelimitedWithIOException(GeneratedMessageV3.java:347)
	at com.google.devtools.build.lib.worker.WorkerProtocol$WorkResponse.parseDelimitedFrom(WorkerProtocol.java:2145)
	at com.google.devtools.build.lib.worker.WorkerSpawnRunner.execInWorker(WorkerSpawnRunner.java:349)
	at com.google.devtools.build.lib.worker.WorkerSpawnRunner.actuallyExec(WorkerSpawnRunner.java:172)
	at com.google.devtools.build.lib.worker.WorkerSpawnRunner.exec(WorkerSpawnRunner.java:121)
	at com.google.devtools.build.lib.exec.SpawnRunner.execAsync(SpawnRunner.java:224)
	at com.google.devtools.build.lib.exec.AbstractSpawnStrategy.exec(AbstractSpawnStrategy.java:113)
	at com.google.devtools.build.lib.exec.AbstractSpawnStrategy.exec(AbstractSpawnStrategy.java:78)
	at com.google.devtools.build.lib.actions.SpawnActionContext.beginExecution(SpawnActionContext.java:41)
	at com.google.devtools.build.lib.exec.ProxySpawnActionContext.beginExecution(ProxySpawnActionContext.java:60)
	at com.google.devtools.build.lib.actions.SpawnContinuation$1.execute(SpawnContinuation.java:80)
	at com.google.devtools.build.lib.rules.java.JavaCompileAction$JavaActionContinuation.execute(JavaCompileAction.java:514)
	at com.google.devtools.build.lib.rules.java.JavaCompileAction.beginExecution(JavaCompileAction.java:310)
	at com.google.devtools.build.lib.rules.java.JavaCompileAction.execute(JavaCompileAction.java:317)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$4.execute(SkyframeActionExecutor.java:830)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$ActionRunner.continueAction(SkyframeActionExecutor.java:965)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$ActionRunner.run(SkyframeActionExecutor.java:937)
	at com.google.devtools.build.lib.skyframe.ActionExecutionState.runStateMachine(ActionExecutionState.java:114)
	at com.google.devtools.build.lib.skyframe.ActionExecutionState.getResultOrDependOnFuture(ActionExecutionState.java:78)
	at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor.executeAction(SkyframeActionExecutor.java:563)
	at com.google.devtools.build.lib.skyframe.ActionExecutionFunction.checkCacheAndExecuteIfNeeded(ActionExecutionFunction.java:707)
	at com.google.devtools.build.lib.skyframe.ActionExecutionFunction.compute(ActionExecutionFunction.java:253)
	at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:453)
	at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:387)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
---8<---8<--- End of exception details ---8<---8<---

---8<---8<--- Start of log ---8<---8<---
-Xbootclasspath/p is no longer a supported option.
ion.
---8<---8<--- End of log ---8<---8<---
INFO: Elapsed time: 0.497s, Critical Path: 0.10s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

I’m unsure what to make of this difference in results, but I’d love to get to a point where I feel confident in what jdk is being used. Quite likely I’m confused out of my mind here.

What operating system are you running Bazel on?

Mac OS X 10.14.4

What’s the output of bazel info release?

release 0.25.2

Have you found anything relevant by searching the web?

I have not, the only thing has been Bazel’s own documentation on toolchains, which doesn’t cover the Java situation in detail. I did ask in the Bazel slack #general channel, and @laszlocsomor was very helpful

[iirina]

@davidsantiago thank you for your feedback! I agree that documentation on Java toolchains is long due and should be prioritized.

[nkoroste]

related: https://github.com/bazelbuild/rules_kotlin/issues/188