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

Prefer Guava version of VisibleForTesting annotation #2505

Merged
merged 4 commits into from
Mar 8, 2023

Conversation

ash211
Copy link
Contributor

@ash211 ash211 commented Mar 6, 2023

Before this PR

There are multiple versions of the @VisibleForTesting annotation, and if a developer isn't careful they can inadvertently import a version of that annotation besides the main one from Guava.

After this PR

==COMMIT_MSG==
Prefer Guava version of VisibleForTesting annotation
==COMMIT_MSG==

This PR makes importing

Possible downsides?

Repos with -Werror that trip this warning will now fail to compile. However, they have opted into this behavior by enabling -Werror and their CI checks should prevent gradle-baseline auto-upgrades from breaking their main branches. However, they would then be stuck on the previous version of gradle-baseline, and not receive future updates to gradle-baseline automatically via excavator auto-bumps.

@ash211 ash211 requested a review from pkoenig10 March 6, 2023 22:27
@changelog-app
Copy link

changelog-app bot commented Mar 6, 2023

Generate changelog in changelog/@unreleased

Type

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

Prefer Guava version of VisibleForTesting annotation

Check the box to generate changelog(s)

  • Generate changelog entry

Comment on lines 44 to 58
private static final Set<String> OTHER_VFTS = Set.of(
"org.apache.hadoop.thirdparty.com.google.common.annotations.VisibleForTesting",
"org.jetbrains.annotations.VisibleForTesting",
"com.facebook.react.common.annotations.VisibleForTesting",
"org.apache.arrow.util.VisibleForTesting",
"org.assertj.core.util.VisibleForTesting",
"org.apache.flink.annotation.VisibleForTesting",
"com.cronutils.utils.VisibleForTesting",
"com.google.api.client.repackaged.com.google.common.annotations.VisibleForTesting",
"org.sparkproject.guava.annotations.VisibleForTesting",
"org.apache.hadoop.classification.VisibleForTesting",
"org.jheaps.annotations.VisibleForTesting",
"io.debezium.annotation.VisibleForTesting",
"graphql.VisibleForTesting",
"avro.shaded.com.google.common.annotations.VisibleForTesting");
Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer to avoid explicitly listing these and just forbid any annotation named "VisibleForTesting" that isn't the error-prone one.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agree with Patrick, I think we may also want to consider blocking some of these repackaged imports in the baseline checkstyle as well by expanding IllegalImports:

<module name="IllegalImport"> <!-- Java Coding Guidelines: Import the canonical package -->
<property name="id" value="BanShadedClasses"/>
<property name="illegalPkgs" value=".*\.(repackaged|shaded|thirdparty)"/>
<property name="regexp" value="true"/>
<message key="import.illegal" value="Must not import repackaged classes."/>
</module>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed the deny list of imports and instead now look for all imports with the same class name.

Is it a requirement to change Checkstyle at the same time as ErrorProne, or can they be independent? The EP change seems better to me, because it can suggest and apply fixes.

*/
@AutoService(BugChecker.class)
@BugPattern(summary = "Prefer Guava's @VisibleForTesting over other versions.", severity = SeverityLevel.WARNING)
public final class PreferGuavaVisibleForTesting extends BugChecker implements ImportTreeMatcher {
Copy link
Member

Choose a reason for hiding this comment

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

These are Error-Prone annotations, not Guava

Suggested change
public final class PreferGuavaVisibleForTesting extends BugChecker implements ImportTreeMatcher {
public final class PreferErrorProneAnnotations extends BugChecker implements ImportTreeMatcher {

WDYT about reframing/restructuring this as a general PreferErrorProneAnnotations check so we can add other annotations here in the future?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm pretty sure that VisibleForTesting exists in standard guava without error-prone annotation apis.

Copy link
Contributor

Choose a reason for hiding this comment

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

@VisibleForTesting has been in standard Guava since was renamed from Google-collections in 2010.

We may want to consider something like PreferCommonAnnotations to steer folks to preferred annotations like cases like this, nullness, etc.

We'll likely be deconflicting between checker-framework,
jspecify, guava, legacy jsr305 & findbugs/spotbugs, etc. and ideally consolidating on the smallest combination of these.

Copy link
Member

@pkoenig10 pkoenig10 Mar 7, 2023

Choose a reason for hiding this comment

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

Ah sorry, I didn't look closely enough here. I thought this was for an EP annotation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed to PreferCommonAnnotations. If there are other annotations like VisibleForTesting we'd like to add now, please lmk. I don't know of others, and am happy to get just this one in.

@schlosna
Copy link
Contributor

schlosna commented Mar 8, 2023

Minor perf suggestion

@ash211 ash211 requested a review from schlosna March 8, 2023 05:09
Copy link
Contributor

@schlosna schlosna left a comment

Choose a reason for hiding this comment

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

seems reasonable to me

Comment on lines +86 to +89
"import org.jetbrains.annotations.*;",
"public final class Client {",
// NOTE: wildcard-imported annotations are not currently re-written
" @VisibleForTesting",
Copy link
Contributor

Choose a reason for hiding this comment

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

this seems ok for now given we block wildcard imports

Comment on lines +71 to +72
// NOTE: fully-qualified annotations are not currently re-written
" @org.jetbrains.annotations.VisibleForTesting",
Copy link
Contributor

Choose a reason for hiding this comment

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

seems reasonable to allow fully qualified as method to explicitly use different type

bulldozer-bot bot pushed a commit to palantir/witchcraft-api that referenced this pull request Mar 12, 2023
###### _excavator_ is a bot for automating changes across repositories.

Changes produced by the roomba/latest-baseline-oss check.

# Release Notes
## 4.189.0
| Type | Description | Link |
| ---- | ----------- | ---- |
| Improvement | Upgrade error_prone to 2.18.0 (from 2.16) | palantir/gradle-baseline#2472 |


## 4.190.0
| Type | Description | Link |
| ---- | ----------- | ---- |
| Feature | Added `DangerousCollapseKeysUsage` error prone check to disallow usage of `collapseKeys()` API of `EntryStream`. | palantir/gradle-baseline#2291 |
| Feature | Prefer common versions of annotations over other copies | palantir/gradle-baseline#2505 |



To enable or disable this check, please contact the maintainers of Excavator.
This was referenced Mar 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants