Test coverage doesn't work on Java 16 toolchain #13358
Comments
comius
added
team-Rules-Java
|
I activated the coverage tests for Java 16 toolchain again to demonstrate the failure: #13361. |
|
/cc @c-mita |
|
The zip it's crashing on is That jar is created by the singlejar invocation in the log, which is printing errors: The correct path appears to be e.g.: -execroot/__main__/bazel-out/k8-fastbuild/bin/test.runfiles/__main__/java_tools/JacocoCoverage_jarjar_deploy.jar
+execroot/__main__/bazel-out/k8-fastbuild/bin/test.runfiles/remote_java_tools/java_tools/JacocoCoverage_jarjar_deploy.jarThe paths in the singlejar command line are being constructed here: bazel/tools/test/collect_coverage.sh Lines 135 to 139 in 414f3c8 I'm still confused about what actually changed in JDK 16, as far as I can tell under earlier JDK versions the singlejar command line was also malformed and I almost wonder if something in JDK 16 changed the behaviour of the shutdown hook in |
|
Thanks for analysis. I also saw the same issues with Java 15 toolchain. classpath file is misconfigured and resulted merged jar cannot be read, but there is no error in Java 15 toolchain. I have problem to reproduce the failure on command line. With this diff: diff --git a/src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt b/src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt
index 4394666ab6..8ad81c9fef 100644
--- a/src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt
+++ b/src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt
@@ -1,4 +1,4 @@
-#!/usr/bin/env bash
+#!/bin/bash -x
# Copyright 2014 The Bazel Authors. All rights reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");I can see the command that is executed: However, if I re-run the command: there is no failure. |
|
This is fixed by 8ba48ad |
|
Thanks, I can confirm that coverage works now on Bazel@HEAD. Still the #13361 is needed to enable the disabled coverage tests for Java 16 toolchain. |
|
Can you please reopen this issue? Turns out another coverage test is still failing on Java 16 toolchain, even with 8ba48ad included (as can be seen in the PR linked to this issue). I extracted this reproducer: https://github.com/davido/bazel_cov. |
|
This looks like it has a similar root cause to the other issue: the coverage runtime classpath contains an entry that doesn't exist, which is now failing the test. I think the paths were wrong all along, it was just being silently ignored before. The test depends on that deploy jar via Note I'm a little confused about data.
|
|
Yes, even if I run coverage with vanilla Java 11 toolchain, also with this diff in reproducer: diff --git a/.bazelrc b/.bazelrc
index c5e3cb0..5f419bd 100644
--- a/.bazelrc
+++ b/.bazelrc
@@ -1,6 +1,6 @@
# Builds using remote_jdk16, executes using remote_jdk16 or local_jdk
-build --java_language_version=16
-build --java_runtime_version=16
-build --tool_java_language_version=16
-build --tool_java_runtime_version=16
+#build --java_language_version=16
+#build --java_runtime_version=16
+#build --tool_java_language_version=16
+#build --tool_java_runtime_version=16
I'm still getting exactly the same misconfigured classpath: I also observe the same behavior for Java 15 toolchain. For some reasons it's only failing for Java 16 toolchain, while the root cause exists for all supported toolchains. |
|
I too am seeing |
|
This appears to be fixed at HEAD (after #15209). I don't know what changed in java_tools to fix it though. |
The problem was fixed in latest java_tools release. Remove duplicated variable, as it's the same now. Closes bazelbuild#13358.
Thanks, I confirmed, that the tests are passing now, and I've updated my linked PR and removed duplicated variable definition. |
Trying to run test coverage with new and shiny Java 16 toolchain support is failing.
Reproducer: https://github.com/davido/bazel_coverage. Note, that .bazelrc already switching to Java 16 toolchain, you make sure, that your bazel version includes this PR.
The problem could be related to some new visibility/exports requirement in JDK16?
The full log is here:
//CC @cushon @comius
The text was updated successfully, but these errors were encountered: