Closed niloc132 closed 2 years ago
Thanks for the detailed report. Do you already have a patch?
I'm little bit surprised. We have unit tests covering GwtIncompatibleStripperTest behavior. Are we missing something there?
I haven't dug in to the code to see where it is coming from except to say that I can't see where it is coming from :). I definitely agree that the tests look like they should cover this case, so my hunch is that it is somehow IO related - the tests appear to validate the strings, and so perhaps OutputUtils is doing something it shouldn't? I'm afraid that's as far as I've gotten.
I have a theory. Will send a quick lazy fix without trying to repro...
(I'm pretty confident that this should fix it but pls re-open if it is not fixed)
Describe the bug
.java
files with no@GwtIncompatible
annotation have an extra newline appended to the end after they are processed by the GwtIncompatibleStripper. I have not validated if files which do contain a@GwtIncompatible
annotation are also affected in this way.To Reproduce Method one, in J2CL itself, using Bazel to build:
.java
file in the j2cl JRE, for examplejre/java/java/io/Serializable.java
- as ofd3835de97
this file has 44 lines.bazel build //jre/java:*
to build the JRE.Method two, running the preprocessor directly on a single file, without Bazel:
bazel build //tools/java/com/google/j2cl/tools/gwtincompatible:GwtIncompatibleStripper_deploy.jar
package-info.java
with a single line,package com.hello.world;
. Verify the number of lines in the file.java -jar bazel-bin/tools/java/com/google/j2cl/tools/gwtincompatible/GwtIncompatibleStripper_deploy.jar package-info.java
(note that this will apparently update the file in place).Bazel version Please include version of Bazel that you are running J2CL with:
Expected behavior A clear and concise description of what you expected to happen. Files that require no changes by the preprocessor should have no changes made to them.