Open anderswisch opened 1 month ago
@cushon
I have an initial fix that I verified against the original repro (using the steps in https://github.com/bazelbuild/java_tools/issues/43#issuecomment-2278179422, if anyone knows a better way to have tested that I'm all ears):
$ /tmp/bazel build :tests
...
src/test/java/com/example/myproject/TestRecordBuilderTest.java:10: error: cannot find symbol
assertEquals(new TestRecord(1, "2"), TestRecordBuilder.builder().a(1).b("2").build());
^
symbol: method a(int)
location: class TestRecordBuilder
$ /tmp/bazel build --override_repository=rules_java++toolchains+remote_java_tools=/tmp/java_tools :tests
...
Build completed successfully
One complication is that the easiest way to support those APIs in turbine is to raise the minimum supported JDK version to JDK 17. I'm not sure if that's fine at this point, or if that will mean using older versions of turbine in some configurations.
One complication is that the easiest way to support those APIs in turbine is to raise the minimum supported JDK version to JDK 17. I'm not sure if that's fine at this point, or if that will mean using older versions of turbine in some configurations.
Since this would only affect the JDK used for compilation, I wouldn't consider this a problem. But if you have concerns, I could work out the diff required to keep Turbine compatible with Java 8.
Thanks, I don't have a current sense of which JDK versions people are relying on for compilation, I will try raising the min JDK for turbine and see how that goes.
If it came to it, one option would be to create a Java 8-compatible branch of turbine and then backport any essential bug fixes to it. Most of the recent changes have been related to newer language features, I don't think many changes will be required for Java 8 support.
Description of the bug:
record-builder, an annotation processor that generates code for Java records, produces incorrect output when it runs in the processing environment Bazel uses to generate header JARs. For example, the API for a record's generated builder in a header JAR will be missing all methods related to the source record's components.
The processing environment used to generate header JARs seems to be Turbine 0.6.0 in the latest version of Bazel (7.2.1). Record Builder uses [TypeElement.getRecordComponents()](https://docs.oracle.com/en/java/javase/17/docs/api/java.compiler/javax/lang/model/element/TypeElement.html#getRecordComponents()) to access record components, but Turbine returns an empty list from this method (because it does not implement it). Record Builder also uses RecordComponentElement to read annotations on the record component's accessor, but Turbine does not seem to be able to return this type.
Which category does this issue belong to?
Java Rules
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Modifying the java-maven example:
Then running:
Produces error:
Which operating system are you running Bazel on?
macOS 14.5 (23F79)
What is the output of
bazel info release
?release 7.2.1
If
bazel info release
returnsdevelopment 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 HEAD
?No response
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response