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

Fix error prone warns #2320

Merged
merged 57 commits into from
Mar 1, 2023
Merged

Conversation

MaicolAntali
Copy link
Contributor

@MaicolAntali MaicolAntali commented Feb 18, 2023

This PR fix all warns given by ErrorProne.

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.

Thanks!

The reason for the build failure seems to be that Javadoc is generated with Java 11 as target (to document the module descriptor), but the module-info.java file does not declare the dependency on the error_prone_annotations module.
You have to add the following to the module-info.java file:

requires com.google.errorprone.annotations;

(ideally somewhere between the exports and the requires static lines, to keep them ordered)

Most likely that issue would also have occurred if we compiled against Java >= 9, but we are not doing that at the moment.

This PR should fix the latest warnings given by ErrorProne. (If I haven't missed someone

Do you want to try adding <failOnWarning>true</failOnWarning> again now?

Also, is this pull request done, or are you planning to extend it? Could you please refine the exclusion for the proto module, as mentioned in #2316 (comment)? It looks like the non-generated code of the proto module only has one or two warnings.

In general, maybe it would also be easier to have one pull request (this one here for example now) where you address the error-prone warnings, instead of multiple. You could for example also mark it as draft to indicate that it is not complete yet. Also no hurry, take your time.

gson/pom.xml Outdated Show resolved Hide resolved
@Marcono1234
Copy link
Collaborator

You can also add the following here to the pom.xml

<link>https://errorprone.info/api/latest/</link>

This will then from Gson's Javadoc add links for the @InlineMe annotations of JsonParser.

@MaicolAntali
Copy link
Contributor Author

The reason for the build failure seems to be that Javadoc is generated with Java 11 as target (to document the module descriptor), but the module-info.java file does not declare the dependency on the error_prone_annotations module.

Thanks! Yesterday I was struggling to understand why the build was failing.


Do you want to try adding <failOnWarning>true</failOnWarning> again now?

Yep, I have just tried. I had to push another commit, but now, yes, everything work fine also with the <failOnWarning>true</failOnWarning>.


Also, is this pull request done, or are you planning to extend it? Could you please refine the exclusion for the proto module, as mentioned in #2316 (comment)? It looks like the non-generated code of the proto module only has one or two warnings.

Yes, I want to go further and fix every warns given by ErrorProne


In general, maybe it would also be easier to have one pull request (this one here for example now) where you address the error-prone warnings, instead of multiple. You could for example also mark it as draft to indicate that it is not complete yet. Also no hurry, take your time.

I appreciate your advice. I'm new in the open-source world and I want learn as much as possible so thanks! 😃

@MaicolAntali MaicolAntali marked this pull request as draft February 19, 2023 14:25
Replaces `.*proto.*` with `.*/generated-test-sources/protobuf/.*` in such way will be excluded just the generated code and not the whole `proto` directory
Removes the `descriptor` variable because is unused.
Removes the `gson/src/test.*` path from the `-XepExcludedPaths` parameter of the ErrorProne plugin
This commit fix all `UnusedVariable` warns given by ErrorProne in the `gson/src/test.*` path.

Some field is annotated with `@Keep` that means is used by reflection.
In some other case the record is annotated with `@SuppressWarnings("unused")`
This commit fix all `JavaUtilDate` warns given by ErrorProne in the `gson/src/test.*` path.

Classes/Methods are annotated with `@SuppressWarnings("JavaUtilDate")` because it's not possible use differente Date API.
This commit fix all `EqualsGetClass` warns given by ErrorProne in the `gson/src/test.*` path.

I have rewrite the `equals()` methods to use `instanceof`
@Marcono1234
Copy link
Collaborator

Thanks for addressing the comments!

In general, maybe it would also be easier to have one pull request (this one here for example now) where you address the error-prone warnings, instead of multiple. You could for example also mark it as draft to indicate that it is not complete yet. Also no hurry, take your time.

I appreciate your advice. I'm new in the open-source world and I want learn as much as possible so thanks! 😃

You are welcome 🙂! I think it is often the case that one discovers features of GitHub (or maybe in general of any tool), when they see someone else using or mentioning it.

Also to avoid any misunderstanding, personally I think it can be useful in some cases to split large pull requests to make reviewing and testing their changes easier. But here in this case I think the changes are small enough to keep them all in one pull request.

gson/src/main/java/com/google/gson/stream/JsonReader.java Outdated Show resolved Hide resolved
return false;
} else if (!stringValue.equals(other.stringValue))
}
if (!(o instanceof BagOfPrimitives)) {
Copy link
Member

Choose a reason for hiding this comment

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

Did Error Prone suggest changing the getClass() check into this instanceof? I believe it is correct, but I had to study the code a bit to make sure. There is actually a subclass of BagOfPrimitives called SubTypeOfBagOfPrimitives in JsonTreeTest which adds an extra field. But it doesn't override equals and the test doesn't rely on equals, so I think it is OK that an instance of BagOfPrimitives can now equal an instance of SubTypeOfBagOfPrimitives where it couldn't before.

@@ -233,7 +226,7 @@ public static class ClassWithNoFields {
// Nothing here..
@Override
public boolean equals(Object other) {
return other.getClass() == ClassWithNoFields.class;
return other instanceof ClassWithNoFields;
Copy link
Member

Choose a reason for hiding this comment

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

Again this has subclasses (anonymous ones) in ObjectTest, but I don't think the change in equals semantics matters.

gson/pom.xml Outdated Show resolved Hide resolved
This commit fix all `JdkObsolete` warns given by ErrorProne in the `gson/src/test.*` path.

In some cases I have replaced the obsolete JDK classes with the newest alternatives.  In other cases, I have added the `@SuppressWarnings("JdkObsolete")`
Copy link
Member

@eamonnmcmanus eamonnmcmanus left a comment

Choose a reason for hiding this comment

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

Not quite done reviewing but here's what I have so far.

gson/src/test/java/com/google/gson/CommentsTest.java Outdated Show resolved Hide resolved
gson/src/test/java/com/google/gson/JsonArrayTest.java Outdated Show resolved Hide resolved
gson/src/test/java/com/google/gson/JsonNullTest.java Outdated Show resolved Hide resolved
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.

This really shows that integration of Error Prone was worth it! It discovered multiple flaws in the existing tests already.

@MaicolAntali
Copy link
Contributor Author

MaicolAntali commented Feb 24, 2023

I tried to fix this but lambdas are not supported in JDK 7 so the build fails.

@eamonnmcmanus
Copy link
Member

I tried to fix this but lambdas are not supported in JDK 7 so the build fails.

Are you up for modifying pom.xml so that tests are run with --release 11 even though the main code is compiled with --release 7? The Continuous Integration runs with JDK 11 and 17 so that should be fine. It would be a separate PR, and don't feel obliged, especially if you are not very well acquainted with Maven.

Truth be told, I think we could probably target Java 8 now. As far as I know recent Android tooling works quite well with that. But that's a bigger step that would require deeper investigation.

@MaicolAntali MaicolAntali marked this pull request as ready for review February 28, 2023 09:25
Copy link
Member

@eamonnmcmanus eamonnmcmanus left a comment

Choose a reason for hiding this comment

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

I think this is ready to go? Maybe you could just Resolve the remaining open conversations.

@MaicolAntali
Copy link
Contributor Author

I think that pretty much everything is fixed.

@eamonnmcmanus
Copy link
Member

This is great. Thanks again!

@eamonnmcmanus eamonnmcmanus merged commit dc20b75 into google:master Mar 1, 2023
@MaicolAntali MaicolAntali deleted the fix-error-prone-warns branch March 2, 2023 09:31
@Marcono1234
Copy link
Collaborator

Since all warnings are fixed or suppressed now, should we consider setting <failOnWarning>true</failOnWarning> again in a follow-up PR?
Otherwise in the future newly introduced warnings might be overlooked.

@eamonnmcmanus
Copy link
Member

Since all warnings are fixed or suppressed now, should we consider setting <failOnWarning>true</failOnWarning> again in a follow-up PR?

+1

@Marcono1234
Copy link
Collaborator

Marcono1234 commented Mar 5, 2023

Turns out the optional dependency on Error Prone Annotations is not ideal; due to JDK-6365854 the compiler will emit warnings when someone uses JsonParser in their project, without having declared a dependency on Error Prone Annotations:

\gson\target\gson-2.10.2-SNAPSHOT.jar(/com/google/gson/JsonParser.class): warning: Cannot find annotation method 'replacement()' in type 'InlineMe': class file for com.google.errorprone.annotations.InlineMe not found
\gson\target\gson-2.10.2-SNAPSHOT.jar(/com/google/gson/JsonParser.class): warning: Cannot find annotation method 'imports()' in type 'InlineMe'
\gson\target\gson-2.10.2-SNAPSHOT.jar(/com/google/gson/JsonParser.class): warning: Cannot find annotation method 'replacement()' in type 'InlineMe'
\gson\target\gson-2.10.2-SNAPSHOT.jar(/com/google/gson/JsonParser.class): warning: Cannot find annotation method 'imports()' in type 'InlineMe'
\gson\target\gson-2.10.2-SNAPSHOT.jar(/com/google/gson/JsonParser.class): warning: Cannot find annotation method 'replacement()' in type 'InlineMe'
\gson\target\gson-2.10.2-SNAPSHOT.jar(/com/google/gson/JsonParser.class): warning: Cannot find annotation method 'imports()' in type 'InlineMe'

While this probably won't cause any issues (as mentioned in the JDK bug report above), it will still be confusing since it is not obvious how to solve this problem.

So should we either remove the dependency on Error Prone Annotations (or make it a test-scoped dependency only and remove its usage from JsonParser), or make it a required dependency?

The reason why these warnings are not shown during the Gson Maven build despite gson-extras and other modules depending on gson, without themselves declaring a dependency on Error Prone Annotations is that due to Error Prone usage compilation is run in fork mode.
That means plexus-compiler (used by the Maven Compiler Plugin) parses the process output to determine compiler diagnostics, but apparently it is unable to detect all warnings and errors and in that case produces no messages at all (codehaus-plexus/plexus-compiler#66), and there is currently no way to view the messages unless you run in non-fork mode (which is not possible with Error Prone).

@Marcono1234 Marcono1234 mentioned this pull request Mar 5, 2023
9 tasks
@eamonnmcmanus
Copy link
Member

Huh. Making the dependency non-optional would not be the end of the world, though it would be the first non-optional dependency that Gson has. Another possibility, suggested by my team-mates, would be to add Gson-specific copies of the annotations. Currently we use only @Keep and @InlineMe, and in both cases Error Prone recognizes those annotations regardless of what package they are in. So for example we could add com.google.gson.internal.annotations, or we could add a package-private copy of the annotation to every package that needs it. Maybe it's easiest just to make the dependency non-optional, though.

@cpovirk
Copy link
Member

cpovirk commented Mar 6, 2023

Digression:

unless you run in non-fork mode (which is not possible with Error Prone)

I think that https://errorprone.info/docs/installation#maven no longer requires forking now that Error Prone has dropped support for Java 8. But maybe there are cases in which it's still needed.

But mainly, thanks for pointing out the issue with plexus-compiler's hidden warnings. I had seen that before, but I hadn't connected it to the issue of missing annotation dependencies.

@eamonnmcmanus
Copy link
Member

Also, @cpovirk pointed out that we have similar issues with Guava, where we did decide just to include the annotation dependencies.

@Marcono1234
Copy link
Collaborator

Marcono1234 commented Mar 6, 2023

I think that https://errorprone.info/docs/installation#maven no longer requires forking now that Error Prone has dropped support for Java 8. But maybe there are cases in which it's still needed.

The Error Prone setup here currently specifies the -J options to open the internal packages using the Maven Compiler Plugin, which requires fork mode for -J options. Though maybe we could indeed use the .mvn/jvm.config approach suggested by the Error Prone documentation, that apparently also improves compilation time (see google/error-prone#2786).

Edit: Pull request #2339 changes it to use .mvn/jvm.config

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.

None yet

4 participants