Description of the problem:
There appears to be a return type discrepancy between the ErrorProne JDK that it compiles against, versus OpenJDK. The class is com.sun.tools.javac.code.Symbol. The inner class is CompletionFailure.
Errorprone JDK: CompletionFailure.getDetailValue
public Object getDetailValue() {
return (diag != null ? diag : errmsg);
}
OpenJDK: CompletionFailure.getDetailValue
public JCDiagnostic getDetailValue() {
return getDiagnostic();
}
This discrepancy is leading me to see this during a Bazel build when ErrorProne is invoked:
ERROR: /xyz/BUILD:55:2: Building xyz/src/test/java/a/b/c/Foo-class.jar (2 source files) failed (Exit 1)
compiler message file broken: key=compiler.misc.msg.bug arguments=11.0.1, {1}, {2}, {3}, {4}, {5}, {6}, {7}
java.lang.NoSuchMethodError: com.sun.tools.javac.code.Symbol$CompletionFailure.getDetailValue()Ljava/lang/Object;
at com.google.errorprone.ErrorProneAnalyzer.finished(ErrorProneAnalyzer.java:171)
at com.google.devtools.build.buildjar.javac.plugins.errorprone.ErrorPronePlugin.postFlow(ErrorPronePlugin.java:169)
at com.google.devtools.build.buildjar.javac.BlazeJavaCompiler.flow(BlazeJavaCompiler.java:115)
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1375)
at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:147)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
at com.google.devtools.build.buildjar.javac.BlazeJavacMain.compile(BlazeJavacMain.java:114)
at com.google.devtools.build.buildjar.ReducedClasspathJavaLibraryBuilder.fallback(ReducedClasspathJavaLibraryBuilder.java:107)
at com.google.devtools.build.buildjar.ReducedClasspathJavaLibraryBuilder.compileSources(ReducedClasspathJavaLibraryBuilder.java:67)
at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.compileJavaLibrary(SimpleJavaLibraryBuilder.java:116)
at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:123)
at com.google.devtools.build.buildjar.BazelJavaBuilder.processRequest(BazelJavaBuilder.java:106)
at com.google.devtools.build.buildjar.BazelJavaBuilder.runPersistentWorker(BazelJavaBuilder.java:68)
at com.google.devtools.build.buildjar.BazelJavaBuilder.main(BazelJavaBuilder.java:46)
This is during a logging statement that is about to tell me there is a missing transitive dependency:
Error prone logging statement
Can we eliminate the use of that method in the logging statement, as it seems problematic?
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Mac with OpenJDK 11 + Bazel 1.2.1
JDK 11 is set as the server_javabase, host_javabase, and javabase if you are familiar with Bazel.
I haven't figured out the repro because Bazel fails just as it is about to explain the use case. It has something to do with an upstream transitive dependency being missing, but I have tried to create a simple example and have not found one yet. This original case came from a missing dependency in a big project. Adding that missing dependency worked around this issue, but we had to guess as to what that dependency was until we found it.
What version of Error Prone are you using?
Bazel 1.2.1 / ErrorProne 2.3.3
Have you found anything relevant by searching the web?
No.
Description of the problem:
There appears to be a return type discrepancy between the ErrorProne JDK that it compiles against, versus OpenJDK. The class is com.sun.tools.javac.code.Symbol. The inner class is CompletionFailure.
Errorprone JDK: CompletionFailure.getDetailValue
OpenJDK: CompletionFailure.getDetailValue
This discrepancy is leading me to see this during a Bazel build when ErrorProne is invoked:
This is during a logging statement that is about to tell me there is a missing transitive dependency:
Error prone logging statement
Can we eliminate the use of that method in the logging statement, as it seems problematic?
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Mac with OpenJDK 11 + Bazel 1.2.1
JDK 11 is set as the server_javabase, host_javabase, and javabase if you are familiar with Bazel.
I haven't figured out the repro because Bazel fails just as it is about to explain the use case. It has something to do with an upstream transitive dependency being missing, but I have tried to create a simple example and have not found one yet. This original case came from a missing dependency in a big project. Adding that missing dependency worked around this issue, but we had to guess as to what that dependency was until we found it.
What version of Error Prone are you using?
Bazel 1.2.1 / ErrorProne 2.3.3
Have you found anything relevant by searching the web?
No.