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

Adds Error Prone to the maven-compiler-plugin #2308

Merged
merged 10 commits into from
Feb 6, 2023

Conversation

MaicolAntali
Copy link
Contributor

First at all, I have set up the Error Prone in the pom.xml. I had to remove the <failOnWarning>true</failOnWarning> otherwise the compiler would stop at every warning that Error Prone gives us.

After, I have add some @SuppressWarnings(...) to avoid errors from Error Prone (that stop the compiler)

@MaicolAntali
Copy link
Contributor Author

MaicolAntali commented Feb 1, 2023

Any idea why CIFuzz is failing?

Is it possible that CIFuzz use Java8 and fail due the <compilerArgs>? Error Prone, for java 8, requires different <compilerArgs> as mentioned here: Link

@MaicolAntali MaicolAntali changed the title Add Error Prone to the maven-compiler-plugin Adds Error Prone to the maven-compiler-plugin Feb 1, 2023
@eamonnmcmanus
Copy link
Member

Thanks, this is great!

Any idea why CIFuzz is failing?

I think the key thing is this:

An exception has occurred in the compiler (15.0.2)

It's running with JDK 15, and I don't think Error Prone supports that. Interestingly I found an old PR that I had lost track of, where I was trying to update Guava fuzzing to use JDK 17 instead of 15. Maybe we can do something like that here too. (It would be more convincing if I had actually made that PR work.)

As a short-term alternative, perhaps you could fiddle with Maven profiles so that Error Prone is not enabled if we're on JDK 15.

@MaicolAntali
Copy link
Contributor Author

I have forked oss-fuzz . I will look into the Dockerfile of the Gson project to see if i can run it under jdk-17

@MaicolAntali
Copy link
Contributor Author

Hello @eamonnmcmanus, the PR google/oss-fuzz#9554 have passed all tests. Can you take a look and tell me if it’s everything good? If yes, I will mark the PR as ready to review so that it will no longer a draft

@eamonnmcmanus
Copy link
Member

That's fantastic! Thanks for taking the time to do it.

@MaicolAntali
Copy link
Contributor Author

Most welcome, now we have to wait until the PR will be merged

DavidKorczynski pushed a commit to google/oss-fuzz that referenced this pull request Feb 2, 2023
Copy link
Collaborator

@Marcono1234 Marcono1234 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it risky to use Error Prone with the regular compilation run, and should it be executed in a separate compilation run instead? I am a bit concerned that it hooks into compilation of classes which then end up in the final JAR. Though I am not very familiar with Error Prone, so maybe this is not an issue.

otherwise the compiler would stop at every warning that Error Prone gives us

The question might be though whether the other warnings should be fixed, suppressed or whether the severity should be adjusted for them (possibly in a follow-up PR?). Otherwise it might be difficult to notice newly introduced warnings when there are already a bunch of previously existing warnings.

Comment on lines -60 to +61
@SuppressWarnings("overrides") // for missing hashCode() override
static class Sandwich {
@SuppressWarnings({"overrides", "EqualsHashCode"}) // for missing hashCode() override
static class Sandwich {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe for consistency the indentation for the complete file should be fixed? This file is not that long and the previous JUnit changes already caused some inconsistent indentation within this file too.

Or Éamonn would you prefer not to have this as part of this PR?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine either way. If @MaicolAntali prefers to add suppressions in this PR and remove them later by fixing the code in one or more later PRs, that seems like a good approach.

pom.xml Show resolved Hide resolved
<compilerArgs>
<arg>-XDcompilePolicy=simple</arg>
<arg>-Xplugin:ErrorProne</arg>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably suppress warnings for classes generated by proto module:

Suggested change
<arg>-Xplugin:ErrorProne</arg>
<arg>-Xplugin:ErrorProne -XepExcludedPaths:.*/generated-test-sources/protobuf/.*</arg>

Error Prone's -XepDisableWarningsInGeneratedCode does not seem to work because it relies on @Generated and the protobuf plugin does not add that yet, see xolstice/protobuf-maven-plugin#29.

@@ -35,6 +35,7 @@ public void testEqualsOnEmptyArray() {
}

@Test
@SuppressWarnings("TruthSelfEquals")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be suppressed, see its description.

assertThat(a).isEqualTo(a); below should be changed to assertThat(a.equals(a)).isTrue() (or MoreAsserts.assertEqualsAndHashCode(a, a)?) since this is intended to explicitly test the equals implementation.

Copy link
Contributor Author

@MaicolAntali MaicolAntali Feb 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In #2299, Éamonn said we could use com.google.guava:guava-testlib to simplify assert like this.

Link to comment


I never use guava-testlib so I'm not sure how to do that. I have looked around for some documentations/examples, but I don't find nothing.

I assume we could use some like: new EqualsTester().addEqualityGroup(a).testEquals();

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, right. Personally I think for this PR it would be best to omit these suppressions and change the code to a.equals(a) to fix this issue. If desired we could then add guava-testlib in a separate PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sorry, I should have been more explicit. That is exactly what you can write, and alternatively you can have just one test method with all the different kinds of objects in different equality groups. Something like this:

new EqualsTester()
    .addEqualityGroup(array1, array2) // with equal contents
    .addEqualityGroup(array3, array4) // equal to each other but not array1 or array2
    .addEqualityGroup(object1, object2)
    ...
   .testEquals();

EqualsTester tests that each object in an equality group is equal to itself and to each other object in the group, and not equal to any object in any other group. It also checks that equal objects have equal hashcodes. So it removes a lot of drudgery.

I think that would be a fine project for a separate PR.

@@ -163,6 +163,7 @@ public void testEqualsOnEmptyObject() {
}

@Test
@SuppressWarnings("TruthSelfEquals")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be suppressed, see its description.

@MaicolAntali
Copy link
Contributor Author

MaicolAntali commented Feb 4, 2023

The question might be though whether the other warnings should be fixed, suppressed or whether the severity should be adjusted for them (possibly in a follow-up PR?). Otherwise it might be difficult to notice newly introduced warnings when there are already a bunch of previously existing warnings.

Every warn could be suppressed or fixed. If you look the build log, Error prone returns to you something like that for each warn:

Warning:  /home/runner/work/gson/gson/gson/src/main/java/com/google/gson/internal/LinkedTreeMap.java:[568,12] [ReferenceEquality] Comparison using reference equality instead of value equality
    (see https://errorprone.info/bugpattern/ReferenceEquality)
  Did you mean 'if (Objects.equals(e, header)) {' or 'if (e.equals(header)) {'?

You have 2 possibility: Fix it or Suppress it. If you follow the link https://errorprone.info/bugpattern/ReferenceEquality (Link) there is an explanation of the problem, a way to fix it and a way to suppress it.


possibly in a follow-up PR?

Exactly, The next PR(s) should fix/suppress the warns

@eamonnmcmanus
Copy link
Member

I see this in the CIFuzz logs:

Step 2/8 : RUN apt-get update && apt-get install -y make autoconf automake libtool wget

which I think means that your oss-fuzz change isn't yet active. Otherwise we would see openjdk-17-jdk at the end of that line.

We don't really care about running Error Prone in the CIFuzz build. Would it be very hassly to omit it when running on JDK 15? As a workaround until the CIFuzz thing is working properly.

Comment on lines -60 to +61
@SuppressWarnings("overrides") // for missing hashCode() override
static class Sandwich {
@SuppressWarnings({"overrides", "EqualsHashCode"}) // for missing hashCode() override
static class Sandwich {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine either way. If @MaicolAntali prefers to add suppressions in this PR and remove them later by fixing the code in one or more later PRs, that seems like a good approach.

@@ -35,6 +35,7 @@ public void testEqualsOnEmptyArray() {
}

@Test
@SuppressWarnings("TruthSelfEquals")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sorry, I should have been more explicit. That is exactly what you can write, and alternatively you can have just one test method with all the different kinds of objects in different equality groups. Something like this:

new EqualsTester()
    .addEqualityGroup(array1, array2) // with equal contents
    .addEqualityGroup(array3, array4) // equal to each other but not array1 or array2
    .addEqualityGroup(object1, object2)
    ...
   .testEquals();

EqualsTester tests that each object in an equality group is equal to itself and to each other object in the group, and not equal to any object in any other group. It also checks that equal objects have equal hashcodes. So it removes a lot of drudgery.

I think that would be a fine project for a separate PR.

pom.xml Outdated Show resolved Hide resolved
@eamonnmcmanus
Copy link
Member

Is it risky to use Error Prone with the regular compilation run, and should it be executed in a separate compilation run instead? I am a bit concerned that it hooks into compilation of classes which then end up in the final JAR. Though I am not very familiar with Error Prone, so maybe this is not an issue.

I think it's fine. Error Prone doesn't affect the generated code, except that there won't be any if it detects an error. We use it in all Java compilations at Google.

@eamonnmcmanus
Copy link
Member

This is looking good. Thanks for the CIFuzz workaround! Let me know if this is ready to be merged.

@MaicolAntali
Copy link
Contributor Author

MaicolAntali commented Feb 6, 2023

✅ Ready to be merged

@eamonnmcmanus eamonnmcmanus merged commit 9f26679 into google:master Feb 6, 2023
@MaicolAntali MaicolAntali deleted the error-prone branch February 6, 2023 14:17
eamonnmcmanus pushed a commit to eamonnmcmanus/oss-fuzz that referenced this pull request Mar 15, 2023
tibor-universe pushed a commit to getuniverse/gson that referenced this pull request Sep 14, 2024
* Adds Error Prone to the `pom.xml`

* Adds Error Prone annotations to avoid compiling errors

* Adds profile to run Error Prone in JDK8

* Revert "Adds profile to run Error Prone in JDK8"

This reverts commit 61771d0.

* Fix Error Prone warn

* Add comment to `pom.xml`

* Fix the `@SuppressWarnings("GetClassOnClass")`

* Replace the Error Prone link in the `pom.xml`

* Disable Error Prone with jdk-15`

* Remove a new-line in `pom.xml`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants