Add missing Override annotations

[zbynek]

Used ErrorProne's patch functionality to add override annotations where possible. Used regular expressions to make sure overrides are on a separate line.

This should make it easier to show errorprone warnings during compilation without going through much spam -- this is the most common errorprone as pointed out in #10322 (comment).

[niloc132]

I'm a little hesitant to fix these, like a lot of the other checkstyle issues

• it isn't indicative of a problem, just not the style that we want
• gwt was originally built for old enough java that override didn't exist (so the style wasn't even appropriate)
• there isn't an actual bug being fixed here, just a missing annotation. This could be wrong in two cases - if one of these fails the build with the annotation (but it doesn't), or if the author meant to override a method but wasnt able to or didn't at the time and got the signature wrong (but we can't know what they meant).

From this I tend to say this is better to add in diffs that change related code, to ensure that the author of a given diff did what they expected.

I wonder if we can collect warnings that only apply to the current diff like we do with checkstyle and ensure we fix when we change things, rather than bulk changes like this? From reviewdog/reviewdog#1087 it looks like this should be possible in theory (includes an example with errorprone), but it apparently doesn't work. (My quick attempt to match errorprone+ant, untested via command line, but seems to capture enough for our purposes)

---

The flip side of course is that this is an obvious change (...after one reviews all 2126 changed lines), and if it compiles it must be correct.

If we want this to be required, the build should also be changed to promote this to a compile failure.

[jnehlmeier]

If we want this to be required, the build should also be changed to promote this to a compile failure.

At work we configure errorprone checks which default to warning as error if we prefer the general intent of that check. And yes we do bulk updates to fix these checks (especially when updating errorprone and new checks have been added). We thought about doing it incremental as we came across it but given the code base is large it would probably never come to an end. So these checks would need to default to warning forever.

Fixing them and configure them as error improves code style consistency, makes code more readable, produces less noise during reviews and developers learn something if they run into such compile errors. If the build output is too verbose then warnings are not always noticed and they end up in reviews as well. At least that is my experience.

So in general I would be fine with that bulk change here.

[niloc132]

Agreed, I'm not against it, just want to caution against bulk "I fixed every typo in the project" changes (or worse a deluge of small "fix: Removed final from a private method" PRs from autonomous agents that gotta get those stats up). Ant output is pretty gross already too - though we could turn it up specifically for CI to capture related warnings.

Override is sort of a special case too, since there are so many missing, more than 10x the next most common errorprone warning, about about 2x every other warning combined. If we do fix it and turn up warnings overall, we're adding 2k or so more warnings in CI builds... though at least a few hundred of the next most common types are just a facet of GWT/JS and not going away any time soon.

But if it's important enough to fix, we should ratchet up warn to error, and at least start capturing/alerting other warnings so we can fix/ratchet or downgrade.

[tbroyer]

If we do fix it and turn up warnings overall, we're adding 2k or so more warnings in CI builds... though at least a few hundred of the next most common types are just a facet of GWT/JS and not going away any time soon.

Then those probably should be disabled?

[niloc132]

They all are disabled - -nowarn has been passed to javac via the ant build since the initial svn commit, nearly 20 years ago (though the line has moved a bit according to git, but the value has always been the same):

gwt/common.ant.xml

Line 58 in 4e6ae10

<property name="javac.nowarn" value="true"/>

The greater context is that if you turn that back on (and ask javac to print more than a handful of warnings), you get all these EP issues. #10322 (comment)

Maybe you're saying "if we do this change and if we turn on those other warnings and if we somehow don't make any other changes to isolate/permit accepted issues" then we should disable those checks? But the premise is "let's enable appropriate checks" so I think that's a given?

[jnehlmeier]

Agreed, I'm not against it, just want to caution against bulk "I fixed every typo in the project" changes (or worse a deluge of small "fix: Removed final from a private method" PRs from autonomous agents that gotta get those stats up).

Yes, but we could also settle on some contribution guidelines saying that such bulk updates are generally only accepted from core members with the goal to make better use of errorprone.

If we do fix it and turn up warnings overal

At work we have javac warnings turned on (with some javac warnings excluded) and we disabled ALL errorprone checks which default to warning and showed up when we introduced errorprone or when we update errorprone so we do not get overwhelmed. Then we turn them on in errorprone one by one, fix them and switch them to error.

So yes we should not just remove -nowarn. Errorprone need to be configured first (I don't know out of my head if there is any ep configuration in the ant script with regard to checks).

[tbroyer]

I was specifically talking about those “at least a few hundred of the next most common types [that] are just a facet of GWT/JS”: if we enable warnings (as a whole), then disable those "next most common types" that we don't care about (we've ignored them for all these years, so even if there are "real positives" there, it might not be worth getting the spam of the ones we consider "false positives").

And BTW, if we otherwise don't care at all about warnings (any warning, like today), then we should probably use -epDisableAllWarnings in addition to -nowarn to avoid the work of detecting those warnings and then ignore them anyway (technically, there could be "mandatory warnings" but Error Prone don't produce any of them).

We could also -XepDisableAllWarnings -Xep:MissingOverride:WARN or some other combination (e.g. bumping to error).