-
Notifications
You must be signed in to change notification settings - Fork 134
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
Implement DeprecatedGuavaObjects error-prone migration #1521
Conversation
Generate changelog in
|
.named("equal"); | ||
private static final Matcher<ExpressionTree> HASH_CODE_MATCHER = MethodMatchers.staticMethod() | ||
.onClass("com.google.common.base.Objects") | ||
.named("hashCode"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we treat single arg version differently to map to java.util.Objects.hashCode(Object)
and varargs maps to java.util.Objects.hash(Objects...)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was planning to keep this simple as a direct migration and write a separate check for java.util.Objects.hash(value)
-> java.util.Objects.hashCode(value)
to eventually resolve to the ideal implementation.
That would result in the first refactor run failing in this case, so it might be fine to share the complexity with this check as well. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 your proposal makes sense to me and is additive beyond just the Guava -> java.util conversion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR is #1522
==COMMIT_MSG==
Implement DeprecatedGuavaObjects error-prone migration
==COMMIT_MSG==