Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Writing to standard out from a java annotation processor produces incomprehensible error message #17448

Closed
rfevang opened this issue Feb 8, 2023 · 3 comments
Assignees
Labels
P1 I'll work on this now. (Assignee required) team-Local-Exec Issues and PRs for the Execution (Local) team type: bug

Comments

@rfevang
Copy link

rfevang commented Feb 8, 2023

Description of the bug:

I was trying to reproduce a bug in a minimal test case, and in the process wanted to write things to standard out in an annotation processor. Doing so however makes bazel fail, and not in a way that makes it obvious to a user what is wrong.

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

MyAnnotation.java:

public @interface MyAnnotation{}

MyProcessor.java:

import javax.annotation.processing.*;
import javax.lang.model.element.*;
import java.util.*;

@SupportedAnnotationTypes(value = "MyAnnotation")
public class MyProcessor extends AbstractProcessor {
  public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment environment) {
    System.out.println("Hello from process()!");    
    return false;
  }
}

SomeClass.java:

@MyAnnotation
public class SomeClass {}

BUILD.bazel:

java_library(
    name = "my_annotation",
    srcs = ["MyAnnotation.java"],
)

java_plugin(
    name = "my_processor",
    srcs = ["MyProcessor.java"],
    processor_class = "MyProcessor",
)

java_library(
    name = "some_class",
    srcs = ["SomeClass.java"],
    deps = [":my_annotation"],
    plugins = [":my_processor"],
)

Executing bazel build :some_class results in the following output:

$ bazel build :some_class
INFO: Invocation ID: 46d862af-30ac-4995-9810-010bc7dbf16c
INFO: Analyzed target //:some_class (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
ERROR: /home/fevang/debug/bazel_bug2/BUILD.bazel:12:13: Building libsome_class.jar (1 source file) and running annotation processors (MyProcessor) failed: Worker process did not return a WorkResponse:

---8<---8<--- Start of log, file at /home/fevang/.cache/bazel/_bazel_fevang/de94cda180ac28d114c9ec223c526675/bazel-workers/multiplex-worker-12-Javac.log ---8<---8<---
(empty)
---8<---8<--- End of log ---8<---8<---
Target //:some_class failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.682s, Critical Path: 0.63s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully

Replacing System.out with System.err in MyProcessor.java makes everything work fine (though the output doesn't show up).

Which operating system are you running Bazel on?

Ubuntu 22.04.1 LTS

What is the output of bazel info release?

release 6.0.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

Possibly #11948 is related (same issue?) It's the issue that made me think writing to standard out might be the problem.

Any other information, logs, or outputs that you want to share?

I've seen on a few invocations the processor output (Hello from process()!) ends up in the error message instead of (emtpy), though it's been rare.

@tjgq
Copy link
Contributor

tjgq commented Feb 9, 2023

The Java rules use persistent workers, which communicate with Bazel via their stdin/stdout using a structured message format.

If you're printing things just for the sake of debugging, try disabling wokers (--strategy=Javac=standalone). Then stdout/stderr should work.

@zhengwei143 zhengwei143 added P1 I'll work on this now. (Assignee required) and removed untriaged labels Feb 14, 2023
@larsrc-google
Copy link
Contributor

This problem should be fixed with #14201, but that didn't make it into the 6.0.0 release. I'll make sure it gets into 6.1.0.

@rfevang
Copy link
Author

rfevang commented Feb 14, 2023

Thanks, building from last_green indeed works just fine, I don't know why I didn't try that before submitting this bug report.

It even writing the messages to standard out, very nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 I'll work on this now. (Assignee required) team-Local-Exec Issues and PRs for the Execution (Local) team type: bug
Projects
None yet
Development

No branches or pull requests

5 participants
@tjgq @rfevang @larsrc-google @zhengwei143 and others